>1) because determining which pages are used exclusively by the process
>cannot be achieved by reading /proc/<pid>/map of a single process. As
>far as I can see one needs to read all /proc/<pid>/map files to be able
>to determine which objects are really shared. Additionally there is no
>way to differentiate between a file that is mmap'ed into this specific
>instance and a shared object that is mmap'ed into multiple process spaces.
And how would the kernel know that a particular page is not shared?
The VM system just can't tell in many cases whether there's still
sharing going on or not.
- The library mappings are possibly shared copy-on-write
- The library BSS is not shared
- The stacks are not shared
- The heap is not shared
- Shared memory may be shared or not
- Read-only mappings can be shared or not.
>2) reading all /proc/<pid>/map files is slow and CPU intensive.
that's because the kernel has to compute a bunch of things and you have
to compute them too; having them appear in psinfo would make creating
psinfo likely much more expensive.
The problem of 'pages exclusively used' by a single process is a
relatively hard problem to solve.
It's also not something that is easily kept by the kernel:
- the first process to map a library would need to account for its
use
- the second process using it would cause the first process
exclusive use count to drop
- the last-but-one process exiting would cause the last process'
count to go up
- is it fair to account all the resident pages in a library which
have been broagh in by process A to be accounted toward process B
after A has exited?
I think we need a clearer definition of the problem and whether we, given
the constraints of the current VM system, can actually achieve knowing this
metric; and if not, what alternative metric we do want. And whether we
want the new VM system to do such accounting properly.
Casper
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
