Re: + page-owner-tracking.patch added to -mm tree

[Eduard - Gabriel Munteanu]

On Fri, Apr 03, 2009 at 04:43:44PM +0200, Ingo Molnar wrote:
> 
> * Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:
> 
> > Ingo Molnar wrote:
> >> * Eduard - Gabriel Munteanu <eduard.munteanu@xxxxxxxxxxx> wrote:
> >>
> >>> One thing I'm not sure about this patch is whether it manages to  
> >>> record an allocation only once, i.e. does it log a single event  
> >>> when/if the slab allocator requests pages? Some time ago I sent a  
> >>> patch adding GFP_NOTRACE to gfp.h, but was rejected. Maybe this  
> >>> could be a way out of the mess.
> >>>
> >>> (GFP_NOTRACE would also allow us to log "backend" allocations easily 
> >>> and treat them separately, for the record, or simply filter them 
> >>> out.)
> >>
> >> makes a lot of sense IMO to annotate these via a GFP flag.
> >
> > Yup, make sense. I think I rejected the patch (did I?) because I 
> > wanted to fix the slub/slab mess differently but here it makes 
> > perfect sense.

Uh, I don't remember exactly, not sure who did it.

But to expand on the upside of doing it this way, we could expect to see
something like...

xxxxx	CPU0	GFP_KERNEL			kmalloc
xxxxx	CPU0	GFP_KERNEL | GFP_NOTRACE	__get_free_pages
xxxxx	CPU0	GFP_KERNEL | GFP_NOTRACE	kmalloc
xxxxx	CPU0	GFP_KERNEL			kmem_cache_alloc

So it's easy to see that allocations 2 and 3 are in fact part of the
fourth. It will get confused by IRQs, preemption and sleeping while
allocating, but we could use additional information (e.g. tracking
returned ptr's) to eliminate some/many such confusions in userspace.

> I'm wondering how much could be shared with the kmemcheck's 
> internal-allocation annotations. There's some overlap (although not 
> a full match) i suspect?
> 
> 	Ingo

I had already suggested this to Vegard some time ago. Basically,
kmemcheck should hook to the same tracepoints. As far as I remember,
kmemtrace gets more info out of the allocators, so this should suit
kmemcheck as well. Though this would incur additional overhead for the
latter due to the extra parameters being passed, but kmemcheck is slow
anyway.


	Eduard

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/