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

From: Rohit Seth
Date: Mon Jun 12 2006 - 13:36:07 EST


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

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