Andrew Brown wrote:

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

the potential impact of the process to the virtual address space, and that's what
vmsize shoul report is
exactly what vm_map->size - (stack hardlimit - stack soft limit) is. The process
can at most fault in that amount
of memory. (Not said if shared or not)

> >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.  :)
>

true, what they currently give is a rough (nearly allways to small) approximation
of the memory that is privat for the process,
as mapping /dev/null or mapping with the flag MAP_ANON will break this
approximation.

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