sean finney on 26 Dec 2008 19:23:00 -0800

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

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

(as a side note / etiquette request, please start a new thread when starting 
a new topic, i'm breaking the thread manually here).

On Fri, Dec 26, 2008 at 08:04:41PM -0500, Casey Bralla wrote:
>     * 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
> 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?

i would assume that the order is exactly as prescribed above, but it
wouldn't hurt to try everything backwards to see if it makes sense :)
maybe there's some kind of endianness/signedness assumption that's being made 
in your program (or the kernel code) that's confusing things?

of course i'd consider the linux kernel source authoritative on the
manner, so you might want to go digging through or a git
checkout to see what you can find :)

> 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 strongly recommend reading the bitfields in 64-bit chunks, and then using 
bit-masking macros/inlines to get the data, instead of reading byte-by-byte.
the latter will confuse things quite a bit as soon as you have something that
crosses a byte boundary (i.e. the page shift value) as well as obfuscate
potential bugs.


	#include <stdint.h>
	typedef uint64_t pagedata;
	#define is_swapped(x) ((x)&0x2) // nonzero == yes
	#define page_shift(x) (1<<(((x)>>3)&0x3f)) // bits [55..60]

(the description above was a bit ambiguous about bit 55 btw)

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

in some quick testcode it always "starts" with 6, but "ends" with 0
(i.e. 0x2eec6a0).


Attachment: signature.asc
Description: Digital signature

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --