Casey Bralla on 23 Dec 2008 05:00:53 -0800


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

[PLUG] Virtual -> Physical Memory Mapping Question (Was: "pmap Output Help Needed")


I've been doing some intense googling, and have found many answers to my 
questions on pmap (It is showing virtual memory.  On a 32-bit system, the max 
is 0x800000 (9 Hex digits), but on a 64-bit system like mine, the address 
range is up to 64 GBytes (pmap is showing up to 16 TBytes... not sure why so 
much) Not sure why the Offset is sometimes the same as Address)


However, now I'm stuck trying to determine how virtual memory is mapped into 
physical memory.  This nifty trick is done by the CPU, but I was hoping that 
I could back-trace the mapping by examining /proc files.

I see that the file /proc/vmallocinfo shows virtual addresses and some data 
about them.  If they are mapped to physical addresses (for I/O reasons), the 
physical address is shown.  It also shows info about the number of pages 
assigned, and whether it was assigned by vmalloc or vmap.

But now I'm stuck.  Anybody know how to trace the actual virtual pages to 
physical memory?

Is there a virtual page map table available?





On Monday 22 December 2008 7:51:31 pm Casey Bralla wrote:
> I'm writing an application that examines the memory used by running
> programs. I'm trying to disect the output of pmap, but I'm a little
> confused and hope somebody can help.
>
> My version of pmap is fairly basic, only allowing the "-x", "-d", & "-q"
> parameters, which gives info such as this:
>
>  pmap -d 25849
> 25849:   /bin/bash
> Address           Kbytes Mode  Offset           Device    Mapping
> 0000000000400000     740 r-x-- 0000000000000000 003:00001 bash
> 00000000006b8000       4 r---- 00000000000b8000 003:00001 bash
> 00000000006b9000      40 rw--- 00000000000b9000 003:00001 bash
> 00000000006c3000     384 rw--- 00000000006c3000 000:00000   [ anon ]
> 00007f0b57c27000      44 r-x-- 0000000000000000 003:00001
> libnss_files-2.9.so 00007f0b57c32000    2044 ----- 000000000000b000
> 003:00001 libnss_files-2.9.so 00007f0b57e31000       4 r----
> 000000000000a000 003:00001 libnss_files-2.9.so 00007f0b57e32000       4
> rw--- 000000000000b000 003:00001 libnss_files-2.9.so 00007f0b57e33000     
> 40 r-x-- 0000000000000000 003:00001 libnss_nis-2.9.so 00007f0b57e3d000   
> 2044 ----- 000000000000a000 003:00001 libnss_nis-2.9.so 00007f0b5803c000   
>    4 r---- 0000000000009000 003:00001 libnss_nis-2.9.so 00007f0b5803d000   
>    4 rw--- 000000000000a000 003:00001 libnss_nis-2.9.so 00007f0b5803e000   
>   84 r-x-- 0000000000000000 003:00001 libnsl-2.9.so 00007f0b58053000   
> 2044 ----- 0000000000015000 003:00001 libnsl-2.9.so 00007f0b58252000      
> 4 r---- 0000000000014000 003:00001 libnsl-2.9.so 00007f0b58253000       4
> rw--- 0000000000015000 003:00001 libnsl-2.9.so 00007f0b58254000       8
> rw--- 00007f0b58254000 000:00000   [ anon ] 00007f0b58256000      28 r-x--
> 0000000000000000 003:00001 libnss_compat-2.9.so 00007f0b5825d000    2044
> ----- 0000000000007000 003:00001 libnss_compat-2.9.so 00007f0b5845c000     
>  4 r---- 0000000000006000 003:00001 libnss_compat-2.9.so 00007f0b5845d000  
>     4 rw--- 0000000000007000 003:00001 libnss_compat-2.9.so
> 00007f0b5845e000    1324 r-x-- 0000000000000000 003:00001 libc-2.9.so
> 00007f0b585a9000    2048 ----- 000000000014b000 003:00001 libc-2.9.so
> 00007f0b587a9000      16 r---- 000000000014b000 003:00001 libc-2.9.so
> 00007f0b587ad000       4 rw--- 000000000014f000 003:00001 libc-2.9.so
> 00007f0b587ae000      20 rw--- 00007f0b587ae000 000:00000   [ anon ]
> 00007f0b587b3000       8 r-x-- 0000000000000000 003:00001 libdl-2.9.so
> 00007f0b587b5000    2048 ----- 0000000000002000 003:00001 libdl-2.9.so
> 00007f0b589b5000       4 r---- 0000000000002000 003:00001 libdl-2.9.so
> 00007f0b589b6000       4 rw--- 0000000000003000 003:00001 libdl-2.9.so
> 00007f0b589b7000     296 r-x-- 0000000000000000 003:00001 libncurses.so.5.7
> 00007f0b58a01000    2048 ----- 000000000004a000 003:00001 libncurses.so.5.7
> 00007f0b58c01000      16 r---- 000000000004a000 003:00001 libncurses.so.5.7
> 00007f0b58c05000       4 rw--- 000000000004e000 003:00001 libncurses.so.5.7
> 00007f0b58c06000       4 rw--- 00007f0b58c06000 000:00000   [ anon ]
> 00007f0b58c07000     116 r-x-- 0000000000000000 003:00001 ld-2.9.so
> 00007f0b58ded000       8 rw--- 00007f0b58ded000 000:00000   [ anon ]
> 00007f0b58e1f000      16 rw--- 00007f0b58e1f000 000:00000   [ anon ]
> 00007f0b58e23000       4 r---- 000000000001c000 003:00001 ld-2.9.so
> 00007f0b58e24000       4 rw--- 000000000001d000 003:00001 ld-2.9.so
> 00007fff60e0e000      88 rw--- 00007ffffffe9000 000:00000   [ stack ]
> 00007fff60ffd000       4 r-x-- 00007fff60ffd000 000:00000   [ anon ]
> ffffffffff600000       4 r-x-- 0000000000000000 000:00000   [ anon ]
> mapped: 17668K    writeable/private: 600K    shared: 0K
>
>
>
>
> Here are my questions:
>
> Firstly, the "Address" seems too high.  I have 2 GBytes of RAM, which
> should translate to a maximum address of 0x80000000 (8 Hex digits), yet I
> see addresses of "7fff60ffd000" which is 12 Hex digits.
>
> Is this just "virtual" memory, so it can be bigger than actual physical
> memory?  or did they add 3 digits (which are always zeros) to the end for
> some reason?
>
>
>
>
> Also, I am aware of how the goofy X86 architecture has a base address and
> an offset, but I notice that the offset is sometimes exactly equal to the
> base address.  (This can't be a coincidence.)
>
> Can somebody explain what these 2 memory addresses are really telling me?
>
> Thanks!
>
>
>
> PS:  Oh my gosh!  This post is "on topic", which is kind of rare for me.
> Hmmmm....   [Thinking Fast!] Actually, my beagle needs to know this! 
> <grin>



-- 


Casey Bralla
Chief Nerd in Residence
The NerdWorld Organisation
___________________________________________________________________________
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