Walt Mankowski on 26 Dec 2008 17:47:11 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] 64bit Numbers in C & /proc/pid/pagemap

Well, the short answer is that I don't know, but I can offer a few

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.


Attachment: signature.asc
Description: Digital signature

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