Subject: Re: vm size wrongly reported
To: Andrew Brown <email@example.com>
From: Lars Heidieker <firstname.lastname@example.org>
Date: 05/04/2003 20:24:59
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
that the vm_map can not expand mappings downwards (concat mappings) only
> 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
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.
> 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" >-----|
> email@example.com * "ah! i see you have the internet
> firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
> email@example.com * "information is power -- share the wealth."
Die mystischen Erklärungen gelten für tief;
die Wahrheit ist, daß sie noch nicht einmal oberflächlich sind.