Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Jul 2012 02:07:58 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Ian Lepore <freebsd@damnhippie.dyndns.org>
Cc:        Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl>, freebsd-hackers@freebsd.org
Subject:   Re: /proc filesystem
Message-ID:  <20120712230758.GM2338@deviant.kiev.zoral.com.ua>
In-Reply-To: <1342132918.1123.140.camel@revolution.hippie.lan>
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> <1342132918.1123.140.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help

--S/ewHz4E8nbJzUsO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 12, 2012 at 04:41:58PM -0600, Ian Lepore wrote:
> On Tue, 2012-06-19 at 06:47 +0200, Wojciech Puchar wrote:
> > that is what i need.
> >=20
> > but still need some explanation after using it and reading manual
> >=20
> > 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
> >=20
> >=20
> > 1) Xorg is mapped twice - IMHO first is text/rodata second is data. But=
=20
> > what "REF" really means here and why it is 2 once and 1 second.
ref shows the reference count on the top of the shadow chain.

The Xorg text is mapped read-only private and flags indicate that there
were no writes to the text (e.g. from debuggers to set breakpoints),
so no COW were performed, and no shadows to contain the COW pages were
inserted. You see the reference count 2 because text and data mappings
are separate vm map entries, and both reference the same vm object.

For the Xorg data, there were writes into private writeable mapping, so
you can see in flags that COW was performed, and shadow object installed
over the vnode vm object. Since the shadow object has a single user,
namely the data mapping in the Xorg process, the ref count is 1.

> >=20
> > 2) what really PRES ("private resident") means? df (default) mappings a=
re=20
> > IMHO anonymous maps=3D=3Dprivate data of process. so why RES is nonzero=
 while=20
> > PRES is zero, while on shared code PRES is nonzero and large. what does=
 it=20
> > really means?
> >=20
> > thanks.
> >=20
>=20
> 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.
>=20
> 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
This is wrong, see above for explanation.

Vnode ownership of the vm object does not end in the vm object reference
count increase. Instead, filesystems manually manage vm object creation
and destruction, since it fits with the vnode lifecycle management.

> 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.
>=20
> I don't know why there is no shadow object for the writable data mapping
> and why the refcount is only 1 for that.
There _is_ shadow object, as indicated by flags showing that entry no
longer 'needs copy'.

>=20
> 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.
>=20
> 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.
>=20
> 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?

This is mostly right, except the note that established mappings might
be removed from page tables at any moment, except for wired mappings.

Main point to take is that page residency is different from mapping.

--S/ewHz4E8nbJzUsO
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAk//WM4ACgkQC3+MBN1Mb4gcJgCgkniJ1LFjaR0dNINcJEtmhDXE
YRQAmwf7MbvJ+mu4yFXFZmH3+Qd5rBLe
=hCEJ
-----END PGP SIGNATURE-----

--S/ewHz4E8nbJzUsO--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120712230758.GM2338>