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