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 STARTEND PRT RES PRES REF SHD FL TP PATH 1378 0x40 0x5ac000 r-x 385 415 2 1 CN- vn /usr/local/bin/Xorg 1378 0x7ab000 0x7bc000 rw- 170 1 0 C-- vn /usr/local/bin/Xorg 1378 0x7bc000 0x80 rw- 140 1 0 C-- df 13780x8007ab0000x8007c3000 r-x 240 32 0 CN- vn /libexec/ld-elf.so.1 13780x8007c30000x8007f rw- 430 1 0 C-- df 13780x8007f0x8007f2000 rw-10 4 0 --- dv 13780x8007f20000x8007f4000 rw-20 4 0 --- dv 13780x8007f40000x800874000 rw- 110 4 0 --- dv 13780x8008740000x800884000 rw- 160 4 0 --- dv 13780x8008840000x800895000 rw- 100 1 0 CN- df 13780x8009c20000x8009c5000 rw-30 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: /proc filesystem
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Ian Lepore Sent: Thursday, July 12, 2012 6:42 PM To: Wojciech Puchar Cc: freebsd-hackers@freebsd.org 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 STARTEND PRT RES PRES REF SHD FL TP PATH 1378 0x40 0x5ac000 r-x 385 415 2 1 CN- vn /usr/local/bin/Xorg 1378 0x7ab000 0x7bc000 rw- 170 1 0 C-- vn /usr/local/bin/Xorg 1378 0x7bc000 0x80 rw- 140 1 0 C-- df 13780x8007ab0000x8007c3000 r-x 240 32 0 CN- vn /libexec/ld-elf.so.1 13780x8007c30000x8007f rw- 430 1 0 C-- df 13780x8007f0x8007f2000 rw-10 4 0 --- dv 13780x8007f20000x8007f4000 rw-20 4 0 --- dv 13780x8007f40000x800874000 rw- 110 4 0 --- dv 13780x8008740000x800884000 rw- 160 4 0 --- dv 13780x8008840000x800895000 rw- 100 1 0 CN- df 13780x8009c20000x8009c5000 rw-30 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) adu...@juniper.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /proc filesystem
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 STARTEND PRT RES PRES REF SHD FL TP PATH 1378 0x40 0x5ac000 r-x 385 415 2 1 CN- vn /usr/local/bin/Xorg 1378 0x7ab000 0x7bc000 rw- 170 1 0 C-- vn /usr/local/bin/Xorg 1378 0x7bc000 0x80 rw- 140 1 0 C-- df 13780x8007ab0000x8007c3000 r-x 240 32 0 CN- vn /libexec/ld-elf.so.1 13780x8007c30000x8007f rw- 430 1 0 C-- df 13780x8007f0x8007f2000 rw-10 4 0 --- dv 13780x8007f20000x8007f4000 rw-20 4 0 --- dv 13780x8007f40000x800874000 rw- 110 4 0 --- dv 13780x8008740000x800884000 rw- 160 4 0 --- dv 13780x8008840000x800895000 rw- 100 1 0 CN- df 13780x8009c20000x8009c5000 rw-30 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
/proc filesystem
where can i find description of field of files /proc/*/map ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /proc filesystem
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /proc filesystem
that is what i need. but still need some explanation after using it and reading manual say: PID STARTEND PRT RES PRES REF SHD FL TP PATH 1378 0x40 0x5ac000 r-x 385 415 2 1 CN- vn /usr/local/bin/Xorg 1378 0x7ab000 0x7bc000 rw- 170 1 0 C-- vn /usr/local/bin/Xorg 1378 0x7bc000 0x80 rw- 140 1 0 C-- df 13780x8007ab0000x8007c3000 r-x 240 32 0 CN- vn /libexec/ld-elf.so.1 13780x8007c30000x8007f rw- 430 1 0 C-- df 13780x8007f0x8007f2000 rw-10 4 0 --- dv 13780x8007f20000x8007f4000 rw-20 4 0 --- dv 13780x8007f40000x800874000 rw- 110 4 0 --- dv 13780x8008740000x800884000 rw- 160 4 0 --- dv 13780x8008840000x800895000 rw- 100 1 0 CN- df 13780x8009c20000x8009c5000 rw-30 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
