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 11:40:44AM +0200, Ingo Molnar wrote:
> > * Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Fri, Jul 12, 2013 at 11:15:06AM +0200, Ingo Molnar wrote:
> > > > 
> > > > * Peter Zijlstra <peterz@infradead.org> wrote:
> > > > 
> > > > > 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?
> > > 
> > > *shudder*.. yes. But you're again opening two files. The only advantage 
> > > of this over userspace writing its own files is that the kernel cleans 
> > > things up for you.
> > 
> > Opening of the files only occurs in the instrumentation case, which is 
> > rare. But temporary files would be forced upon the regular usecase 
> > when no instrumentation goes on.
> 
> Well, Colin didn't describe the intended use, but I can imagine a case 
> where its not all that rare. System health monitors might frequently 
> want to update this.

That's true.

So maybe it would be better to offer a tracepoint that allows apps to emit 
such information - to any system monitor around to listen.

If it's made a vsyscall that does not enter the kernel if the process is 
not being monitored would make it very low overhead.

> > So, these 400+ memory ranges are from Firefox's /proc/*/maps file:
> > 
> <snip>
> > 
> > It's about 35% out of 1300+ mappings that Firefox uses.
> > 
> > It is likely that the ---p mappings (about 40 of them) are guard pages.
> > 
> > How do I tell what the remaining anonymous areas are about?
> 
> Well, if you'd ran it within a memory allocator debug framework that 
> would have kept track of this. Typically memory debuggers can keep 
> allocation time stacks etc.
> 
> If I'm not actively debugging firefox I don't give a damn.

Yet people are nosy and find it rather useful to have such 
'heap/stack/vdso/vsyscall' annotations:

 0237c000-0239d000 rw-p 00000000 00:00 0                                  [heap]
 ...
 7fff622af000-7fff622d0000 rw-p 00000000 00:00 0                          [stack]
 7fff623fe000-7fff62400000 r-xp 00000000 00:00 0                          [vdso]
 ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

and named vmas have names as well:

 7fa5b02eb000-7fa5b6718000 r--p 00000000 08:03 1710237                    /usr/lib/locale/locale-archive

so why not allow some simple mechanism to descriptively name anonymous 
vmas as well?

Maybe the 8 bytes shouldn't be a pointer to user-space memory, but a short 
string, a bit like task_struct:comm[16]?

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>