>> not entirely, since that (for example) includes all space added via
>> mmap(2) (shared libraries, etc).  you almost certainly *don't* want to
>> include shared libraries in the reported size since they're shared.
>
>thats probably where the intuitions falls apart I would like to see such
>mapping accounted,
>as the field is called vmsize in top and ps etc.

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.

>>...
>> vm_ssize says i've used 26 pages out of the two megabyte reservation
>> for stack space.  again, if you used the size field from the vm_map,
>> you'd be counting all of that reservation, plus the empty space from
>> the top of the soft limit to the top of the hard limit (an additional
>> 30 megabytes).  and the shared libraries.  etc.
>
>True, its the 30megs that should not be reported but I don't see any
>trouble with the 2megs from the soft limit,
>thats what happens in a lot of other systems FreeBSD, Solaris...
>This is the point where the problem is.
>Its the fact that memory mapped with mmap on /dev/null device or with
>MAP_ANON flag does not
>increase the reported vmsize and that is strange.

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.

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.

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

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

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