Subject: Re: vm size wrongly reported
To: Lars Heidieker <lars@heidieker.de>
From: Andrew Brown <atatat@atatdot.net>
List: current-users
Date: 05/04/2003 15:39:05
>> 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.
to use pmap(1) again:
% pmap -D2
proc->p_vmspace.vm_map 0xcf834e44 = { pmap = 0xcf445b40,
lock = <struct lock>, header = <struct vm_map_entry>, nentries = 19,
size = 21c2000, ref_count = 1, ref_lock = <struct simplelock>,
hint = 0xcf8f1848, hint_lock = <struct simplelock>,
first_free = 0xcf8f1848, flags = 41 < PAGEABLE TOPDOWN >,
flags_lock = <struct simplelock>, timestamp = 351 }
...
BDC00000 30720K [ stack ]
BFA00000 1920K read/write/exec [ stack ]
BFBE0000 64K read/write/exec [ stack ]
BFBF0000 64K read/write/exec [ stack ]
total 3848K
% bc
3848+30720
34568
obase=16
34568*1024
21C2000
so...it does, but that number is considerably larger than a given
process's impact on the vm system, since a lot of that space is
shared. if you just wanna look at the pages used by a single
process...
% pmap -D24 | sed -n '/am_nused/s/,//gp' | awk '{sum+=$9}END{print sum}'
199
my shell is using 199 pages. that's 796k.
>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.
i'm not sure what you mean by that. so far as i know, the entries in
the vm_map can be expanded in both directions.
>> 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.
very.
>> 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.
they're right from a certain point of view. the problem is that lots
of people have different points of view. :)
--
|-----< "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."