| Walt Mankowski on 26 Dec 2008 17:47:11 -0800 |
|
Well, the short answer is that I don't know, but I can offer a few suggestions. On Fri, Dec 26, 2008 at 08:04:41PM -0500, Casey Bralla wrote: > I'm still working on my application which displays where in memory an > application resides. I have found that there is a relatively new pseudo > file called /proc/pid/pagemap which is a Page Frame table for the process in > question. > > I'm having some trouble reading this data file which, unlike most files in > the /proc directory, is stored as a 64-bit number instead of ASCII characters. > I suspect my difficulties in reading this data are related to my lack of > familiarity with C data structures. Could someone take a look at the > following excerpt from the kernel text file and help me understand a few > things? > > > > Here is the excerpt from /usr/src/linux/Documentation/vm/pagemap.txt > > * /proc/pid/pagemap. This file lets a userspace process find out which > physical frame each virtual page is mapped to. It contains one 64-bit > value for each virtual page, containing the following data (from > fs/proc/task_mmu.c, above pagemap_read): > > * Bits 0-55 page frame number (PFN) if present > * Bits 0-4 swap type if swapped > * Bits 5-55 swap offset if swapped > * Bits 55-60 page shift (page size = 1<<page shift) > * Bit 61 reserved for future use > * Bit 62 page swapped > * Bit 63 page present > > If the page is not present but in swap, then the PFN contains an > encoding of the swap file number and the page's offset into the > swap. Unmapped pages return a null PFN. This allows determining > precisely which pages are mapped (or in swap) and comparing mapped > pages between processes. Well, what's described above isn't really a "C data structure". It's just the layout of the bits in that file. The lowered numbered bits are probably the ones occuring first in the file. > I'm assuming that the first 7 bytes are the the PFN, and that byte 0 (bits 0 - > 7) are the highest order portion, and that bits 48-55 are in the lowest. > Maybe I have this backward? Since it's 64 bits, the lowest ones should be 56-63. Also, I find it a little confusing to read what you wrote since you're mixing bits and bytes. Since you need to extract individual bits, perhaps it would be easier to drop mention of "bytes" and stick to bits? > I'm also assuming that bit 62 would be a "1" if the page is swapped, and a "0" > if it is resident. Bit 62 should be in the 8th byte read from this file, > no? I'd think so, yeah. But it might be easier to read 8 bytes at a time, store them in an 8-bit integer (e.g. a long long in C) and deal with it there. C's bitfields might be useful as well. > The odd thing is that I'm continually seeing almost all zeros in the PFN, and > the last 3 bits are set to "110" (ie: the last hex digit is "6"). This means > that almost every page has the "reserved" bit set, and almost every page > is "swapped". This doesn't make much sense, however, since I have lots of > ram and very little of my swap space is being used. > > > I would appreciate any thoughts or comments from the list. The only other thing I can think of is to see if what you're getting maps to what's in /proc/pid/maps. Walt Attachment:
signature.asc ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|