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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 12, 2013 at 11:40:44AM +0200, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> 
> > On Fri, Jul 12, 2013 at 11:15:06AM +0200, Ingo Molnar wrote:
> > > 
> > > * Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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.

> > However from what I understood android runs apps as individual users, 
> > and I think we can do per user tmpfs mounts. So app dies, user exits, 
> > mount goes *poof*.
> 
> Yes, user-space could be smarter about temporary files.
> 
> Just like big banks could be less risk happy.
> 
> Yet the reality is that if left alone both apps and banks mess up, I don't 
> think libertarianism works for policy: we are better off offering a 
> framework that is simple, robust, self-contained, low risk and hard to 
> mess up?

Fair enough; but I still want Colin to tell me why he can't do this in
userspace. And what all he wants to go do with this information etc.

He's basically not told us much at all.

> 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.

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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]