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