Re: [PATCH]: Adding a counter in vma to indicate the number of physical pages backing it

[Rohit Seth <rohitseth@google.com>]

On Sat, 2006-06-10 at 17:35 +1000, Nick Piggin wrote:
> Rohit Seth wrote:
> > Below is a patch that adds number of physical pages that each vma is
> > using in a process.  Exporting this information to user space
> > using /proc/<pid>/maps interface.
> > 
> > There is currently /proc/<pid>/smaps that prints the detailed
> > information about the usage of physical pages but that is a very
> > expensive operation as it traverses all the PTs (for some one who is
> > just interested in getting that data for each vma).
> 
> Yet more cacheline footprint in the page fault and unmap paths...
> 

Not necessarily.  If I'm doing calculation right then vm_struct is
currently 176 bytes (without the addition of nphys) on my x86_64 box. So
in this case addition would not result in bigger cache foot print of
page fulats. Also currently two adjacent vmas share a cache line.  So
there is already that much of cache line ping pong going on. 

Though I agree that we should try to not extend this size beyond
absolutely necessary.

> What is this used for and why do we want it? Could you do some
> smaps-like interface that can work on ranges of memory, and
> continue to walk pagetables instead?
> 

It is just the price of those walks that makes smaps not an attractive
solution for monitoring purposes.

I'm thinking if it is possible to extend current interfaces (possibly
having a new system call) in such a way that a user land process can
give some hints/preferences to kernel in terms of <pid, virtual_range>
to remove/inactivate.  This can help in keeping the current kernel
behavior for vmscans but at the same time provide little bit of
non-symmetry for user land applications.  Thoughts?

-rohit