Re: [PATCH 2/2] mm: add a field to store names for private anonymous memory

[Ingo Molnar <mingo@kernel.org>]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, Jul 12, 2013 at 10:44:06AM +0200, Ingo Molnar wrote:
> > It makes tons of sense.
> > 
> > Just like we have a task's cmd-name it makes a lot of sense to name 
> > objects in a human readable fashion, to help debugging, instrumentation, 
> > performance analysis, etc.
> > 
> > Yes, in theory user-space could do all that. That's not the point: the 
> > point is to make it fast, easy enough and to have a central version (the 
> > kernel).
> > 
> > Doing it via temporary files has various disadvantages:
> 
> We need those files anyway.. The current proposal is that the entire VMA 
> has a single userspace pointer in it. Or rather a 64bit value.

Yes but accessible via /proc/<PID>/mem or so?

> > I guess the real question is not whether it's useful, I think it 
> > clearly is. The question should be: are there real downsides? Does the 
> > addition to the anon mmap field blow up the size of vma_struct by a 
> > pointer, or is there still space?
> 
> I don't see how the single u64 is useful at all for perf; you can have 
> at most one u64 per page; that's not nearly enough to put symbol 
> information in. Therefore we still require external files.

I was thinking about it in the context of its original purpose: naming 
heap areas, which are pretty anonymous right now - /proc/*/maps is full
of mystery ranges today.

It's indeed not good enough for finer grained structure.

Thanks,

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>