Quantcast

/proc filesystem

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

/proc filesystem

Wojciech Puchar-5
where can i find description of field of files /proc/*/map
?
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /proc filesystem

Andrey Zonov
On 6/18/12 10:31 PM, Wojciech Puchar wrote:
> where can i find description of field of files /proc/*/map
> ?

Use procstat -v instead.  All fields are documented in procstat(1).

--
Andrey Zonov
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /proc filesystem

Wojciech Puchar-5
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.


On Tue, 19 Jun 2012, Andrey Zonov wrote:

> On 6/18/12 10:31 PM, Wojciech Puchar wrote:
>> where can i find description of field of files /proc/*/map
>> ?
>
> Use procstat -v instead.  All fields are documented in procstat(1).
>
> --
> Andrey Zonov
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /proc filesystem

Ian Lepore
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

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: /proc filesystem

Andrew Duane-3
> -----Original Message-----
> From: [hidden email] [mailto:owner-freebsd-
> [hidden email]] On Behalf Of Ian Lepore
> Sent: Thursday, July 12, 2012 6:42 PM
> To: Wojciech Puchar
> Cc: [hidden email]
> Subject: Re: /proc filesystem
>
> 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.

BSS that doesn't exist in the file?

 ...................................
Andrew Duane
Juniper Networks
+1 978-589-0551 (o)
+1 603-770-7088 (m)
[hidden email]

 



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /proc filesystem

Konstantin Belousov
In reply to this post by Ian Lepore
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.
> >
> > 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.
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.

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

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

attachment0 (203 bytes) Download Attachment
Loading...