Andrew Brown wrote:

>
> the problem is then that the total of all the sizes will be
> overreported instead of underreported.  as it stands, it's probably
> overreported somewhat anyway, since the text segments of binaries are
> also shared.
>

if we add them all up yes but just using the size count from vm_map should
give the exact size of the virtual address space, with all the gaps of never
touched memory etc.
The problem I see is the reservation of the stack space and getting along
there without a
"down growing" stack segment is not trival. I think the reason for having this
reservation is
that the vm_map can not expand mappings downwards (concat mappings) only
upwards.

>
> it sounds like what you really want to count is the number of
> allocated anonymous pages, whether they're used to back anonymous
> mappings, or shared mappings that have been copied after a write
> fault, yet even those pages can be shared.
>

That would be much closer to reality but is tricky.

>
> besides, top currently uses sysctl, but there's no way to get
> information that granular out of sysctl.  conceivably, a mechanism
> could be added to allow you to do so, but it would be tricky, highly
> inefficient, and probably error prone.
>
> >> perhaps what you want is something more intelligent that can walk
> >> through the map, entry by entry, and count only:
> >>
> >>     * the text segment
> >>     * the data segment
> >>     * stack segments that are backed by an amap (and only the number
> >>       of used pages there)
> >>     * any other entries backed by anon space up to the size of the
> >>       allocation (or the number of pages?)
> >>
> >> how do you want to count a one megabyte mapping of which i've only
> >> used one page?
> >
> >Just count them as they use up the virtual space, it would then make sense
> >to have reported
> >how much of the virtual space is shared.
>
> it's also non-trivial to find out if shared space is actually being
> shared or not.  for example, libkvm.so is clearly shareable (being a
> shared library), yet there aren't that many things using it, so if you
> find it actually being used, chances are it's only being used once.
> contrast that with libc.so, which is probably being used by
> everything.
>

Yes, ever used the top in MacOSX. It is walking down all the mappings of each
process to find out
if the area is shared or not and as a result it uses about 10% cpu on a G3
400Mhz with an 1 sec
update interval. So this is probably no goog idea.

>
> i'll admit that the numbers aren't "right" for your interpretation,
> but there's no way to make them "right" for all interpretations.
>

true

>
> that said, if you're using current, you can try using pmap(1) to get
> the exact number you want for a given process.
>

I have not trouble with that, beside I'm using current, it is just the fact
the numbers did not look right to me.

>
> --
> |-----< "CODE WARRIOR" >-----|
> codewarrior@daemon.org             * "ah!  i see you have the internet
> twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
> werdna@squooshy.com       * "information is power -- share the wealth."

--
Mystische Erklärungen.
Die mystischen Erklärungen gelten für tief;
die Wahrheit ist, daß sie noch nicht einmal oberflächlich sind.
                --Friedrich Nietzsche