Date: Thu, 12 Jul 2012 16:41:58 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> Cc: freebsd-hackers@freebsd.org Subject: Re: /proc filesystem Message-ID: <1342132918.1123.140.camel@revolution.hippie.lan> In-Reply-To: <alpine.BSF.2.00.1206190639580.1823@wojtek.tensor.gdynia.pl> References: <alpine.BSF.2.00.1206182030570.92893@wojtek.tensor.gdynia.pl> <4FDF8FF1.7020202@zonov.org> <alpine.BSF.2.00.1206190639580.1823@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2012-06-19 at 06:47 +0200, Wojciech Puchar wrote:
> that is what i need.
>
> but still need some explanation after using it and reading manual
>
> say:
> PID START END PRT RES PRES REF SHD FL TP PATH
> 1378 0x400000 0x5ac000 r-x 385 415 2 1 CN- vn /usr/local/bin/Xorg
> 1378 0x7ab000 0x7bc000 rw- 17 0 1 0 C-- vn /usr/local/bin/Xorg
> 1378 0x7bc000 0x800000 rw- 14 0 1 0 C-- df
> 1378 0x8007ab000 0x8007c3000 r-x 24 0 32 0 CN- vn /libexec/ld-elf.so.1
> 1378 0x8007c3000 0x8007f0000 rw- 43 0 1 0 C-- df
> 1378 0x8007f0000 0x8007f2000 rw- 1 0 4 0 --- dv
> 1378 0x8007f2000 0x8007f4000 rw- 2 0 4 0 --- dv
> 1378 0x8007f4000 0x800874000 rw- 11 0 4 0 --- dv
> 1378 0x800874000 0x800884000 rw- 16 0 4 0 --- dv
> 1378 0x800884000 0x800895000 rw- 10 0 1 0 CN- df
> 1378 0x8009c2000 0x8009c5000 rw- 3 0 1 0 C-- df
>
>
> 1) Xorg is mapped twice - IMHO first is text/rodata second is data. But
> what "REF" really means here and why it is 2 once and 1 second.
>
> 2) what really PRES ("private resident") means? df (default) mappings are
> IMHO anonymous maps==private data of process. so why RES is nonzero while
> PRES is zero, while on shared code PRES is nonzero and large. what does it
> really means?
>
> thanks.
>
I'm catching up on threads I was following before I went on vacation,
and it looks like there was never a response to this. I'm interested in
the answers to these questions too, so today I did some spelunking in
the code to see what I could figure out. I don't think I really
understand things too well, but I'll just say what I think I found and
hopefully the experts will correct anything I get wrong.
I think you're right about the first two mappings in that procstat
output. The REF value is the reference count on the vm object (the
vnode for the exe file, I presume). I think the reason the reference
count is 2 is that one reference is the open file itself, and the other
is the shadow object. I've always been a bit confused about the concept
of shadow objects in freebsd's vm, but I think it's somehow related to
the running processes that are based on that executable vnode. For
example, if another copy of Xorg were running, I think REF would be 3,
and SHD would be 2.
I don't know why there is no shadow object for the writable data mapping
and why the refcount is only 1 for that.
The PRES thing seemed simple when I first looked at the code, but the
more I think about it in relation to other numbers the more confused I
get. The logic in the code is "if the shadow count is 1 then PRES is
the resident size of the shadow object." This seems to be a measure of
shared-code usage... any object which could be shared but isn't gets
counted as private resident.
The part that confuses me is how PRES can be larger than RES. The value
for PRES is taken from the resident_page_count field of the shadow
object. The RES value is calculated by walking each page of the map
entry and calling pmap_mincore() to see if it's resident. So the number
of resident pages is calculated to be fewer than the resident_page_count
of the object the entry maps. I don't understand.
Oh hmmm, wait a sec... could it be that read-ahead or relocation fixup
or various other things caused lots of pages to be faulted in for the
vnode object (so they're resident) but not all of those pages are mapped
into the process because the path of execution has never referenced them
and caused faults to map them into the process' vmspace?
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1342132918.1123.140.camel>