Re: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9

["Michal Piotrowski" <michal.k.k.piotrowski@gmail.com>]

On 17/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Hi Catalin,
>
> On 17/08/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > On 13/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > It's kmemleak 0.9 issue. I have tested kmemleak 0.8 on 2.6.18-rc1and
> > > 2.6.18-rc2. I haven't seen this before.
> >
> > it looks like it was caused by commit
> > fc818301a8a39fedd7f0a71f878f29130c72193d where free_block() now calls
> > slab_destroy() with l3->list_lock held.
>
> I'll revert this commit.
>
> >
> > The prio_tree use (which doesn't alloc memory) instead of the
> > radix_tree is about 4 times slower when scanning the memory and I
> > don't think I'll use it.
> >
> > It leaves me with the options of either implementing my own memory
> > allocator based on pages

[MODSLAB 7/7] A slab allocator: Page Slab allocator
"The page slab is a specialized slab allocator that can only handle
page order size object. It directly uses the page allocator to
track the objects and can therefore avoid the overhead of the
slabifier."
http://www.ussg.iu.edu/hypermail/linux/kernel/0608.1/3023.html

>(including a simple hash table instead of
> > radix tree) or fix the locking in kmemleak so that memory allocations
> > happen without memleak_lock held. The latter is a bit complicated as
> > well since any slab allocation causes a re-entrance into kmemleak.
> >
> > Any other suggestions?
>
> Please talk with Christoph Lameter, he is working on Modular Slab.
> http://www.ussg.iu.edu/hypermail/linux/kernel/0608.1/0951.html
> http://www.ussg.iu.edu/hypermail/linux/kernel/0608.2/0030.html
> Maybe he can help with this problem.
>
> >
> > Thanks.
> >
> > --
> > Catalin
> >

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)