Linux MM : virtual memory address space

Fri Mar 7 01:14:32 EST 2014

On Thu, Mar 6, 2014 at 11:18 PM, Subramaniam Appadodharana
<c.a.subramaniam at gmail.com> wrote:
> Jeff/Pramod,
>
> I think what Pramod mentioned is partly right. However, I do not have more
> info on that yet. Will get back after some more digging in. For kernel
> memory
> addresses you can do,
>
> sudo cat /proc/vmallocinfo
>
> This is in line with what Jeff mentioned. I will check why the upper 16 bits
> are set to 1.
>
>
>
> On Thu, Mar 6, 2014 at 11:13 AM, Jeff Haran <Jeff.Haran at citrix.com> wrote:
>>
>> > -----Original Message-----
>> > From: pramod gurav [mailto:pramod.gurav.etc at gmail.com]
>> > Sent: Thursday, March 06, 2014 12:56 AM
>> > To: Jeff Haran
>> > Cc: priyaranjan; kernelnewbies
>> > Subject: Re: Linux MM : virtual memory address space
>> >
>> > On Wed, Mar 5, 2014 at 12:39 AM, Jeff Haran <Jeff.Haran at citrix.com>
>> > wrote:
>> > >
>> > >
>> > >
>> > >
>> > > From: kernelnewbies-bounces at kernelnewbies.org
>> > > [mailto:kernelnewbies-bounces at kernelnewbies.org] On Behalf Of pramod
>> > > gurav
>> > > Sent: Monday, March 03, 2014 11:33 PM
>> > > To: priyaranjan
>> > > Cc: kernelnewbies
>> > > Subject: Re: Linux MM : virtual memory address space
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Mon, Mar 3, 2014 at 11:52 PM, priyaranjan
>> > > <priyaranjan45678 at gmail.com>
>> > > wrote:
>> > >
>> > > I was going through http://linux-mm.org/HighMemory
>> > >
>> > >
>> > > "Currently the 32 bit x86 architecture is the most popular type of
>> > > computer.
>> > > In this architecture, traditionally the Linux kernel has split the 4GB
>> > > of
>> > > virtual memory address space into 3GB for user programs and 1GB for
>> > > the
>> > > kernel"
>> > >
>> > >
>> > >
>> > > What about 64-bit system? Where does the code lie in linux kernel for
>> > > the
>> > > check?
>> > >
>> > > Is there any latest and updated memory management documentation for
>> > > Linux
>> > > kernel?
>> > >
>> > >
>> > >
>> > > Regards,
>> > >
>> > > Priyaranjan
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Priyaranjan,
>> > >
>> > >
>> > >
>> > > As below link suggests:
>> > >
>> > > http://users.nccs.gov/~fwang2/linux/lk_addressing.txt
>> > >
>> > >
>> > >
>> > > Also read this blog written in chinese:
>> > >
>> > >
>> > >
>> > > http://adam8157.info/blog/2012/07/linux-x86-64-vm/
>> > >
>> > >
>> > >
>> > > on 64 bit arch the virtual address space is huge (2 to thr power of
>> > > 64). So
>> > > the overhead of translating the virtual addresses will be high. TO
>> > > avoid
>> > > this only lower 48 bits are used to form virtual addresses.
>> > >
>> > >
>> > >
>> > > I believe this statement about only the lower 48 bits being used it
>> > > not
>> > > correct. That would imply that the upper 16 bits of all virtual
>> > > addresses on
>> > > x86_64 would be the same, which is clearly not the case since the
>> > > upper 16
>> > > bits of user space vas are all 0s yet the upper 16 bits of kernel
>> > > space vas
>> > > are all 1s.
>> > >
>> > >
>> > >
>> > > Jeff Haran
>> > >
>> > >
>> > Hi Jeff,
>> > Just noticed a line in /proc/cpuinfo on my 64 bit linux Machine which
>> > is:
>> >
>> > --> address sizes : 36 bits physical, 48 bits virtual
>> >
>> > This should confirm the statement that, only lower 48 bits are used
>> > for virtual address space on a 64 it arch.
>> > And about upper 16 bits in kernel being 1s in the address range shown
>> > in the link, I think they are not correct.
>>
>> All I can suggest is that you take a kernel and modify it to prink() the
>> virtual address of some kernel data structure (or write a module to do the
>> same) and see for yourself. At least on the x86_64 systems I use, the
>> address of for example a struct sk_buff, which is allocated from a kmem
>> cache, is in the upper end of the 64 bit address range. The top 16 bits are
>> all 1s. Always. This is running recent Redhat EL6, but I believe the same
>> will be true for kernels from kernel.org.
>>
>> Jeff Haran
>>
>>

Jeff, Subbu,

Please refer to the wiki page here,
http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details

This talks about something like canonical form of addresses. A quote
in the page says, " Canonical form addresses run from 0 through
00007FFF'FFFFFFFF, and from FFFF8000'00000000 through
FFFFFFFF'FFFFFFFF, for a total of 256 TB of usable virtual address
space".

Possibly this is the reason we are getting all upper 16 bits in 1s for
kernel virtual address space. which means kernel virtual address space
range on 64 bit arch is  FFFF8000'00000000 - FFFFFFFF'FFFFFFFF which
higher part of 256 TB vurtual address space.  But for user space it is
lower half of 256TB. You need not write a code for this. You ca just
cat memory maps of any process running in system. Example:

gpramod at localhost:$ sudo cat /proc/1/maps

First part is user process mapped in user space virtual address space:
7faf6de70000-7faf6de7c000 r-xp 00000000 08:05 2102384
  /lib/x86_64-linux-gnu/libnss_files-2.15.so
7faf6de7c000-7faf6e07b000 ---p 0000c000 08:05 2102384
  /lib/x86_64-linux-gnu/libnss_files-2.15.so
7faf6e07b000-7faf6e07c000 r--p 0000b000 08:05 2102384
  /lib/x86_64-linux-gnu/libnss_files-2.15.so
7faf6e07c000-7faf6e07d000 rw-p 0000c000 08:05 2102384
  /lib/x86_64-linux-gnu/libnss_files-2.15.so
7faf6e07d000-7faf6e087000 r-xp 00000000 08:05 2102388
  /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7faf6e087000-7faf6e287000 ---p 0000a000 08:05 2102388
  /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7faf6e287000-7faf6e288000 r--p 0000a000 08:05 2102388
  /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7faf6e288000-7faf6e289000 rw-p 0000b000 08:05 2102388
  /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7faf6e289000-7faf6e2a0000 r-xp 00000000 08:05 2102400
  /lib/x86_64-linux-gnu/libnsl-2.15.so
.
.
.
.
.
.
(Last part is Kernel process (system calls) mapped in Kernel virtual
address space:)
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
  [vsyscall]

So what you said is correct about the upper 16 bits being 1s. It also
verifies the "48 bits for virtual address space" theory as well.

>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>

-- 
Thanks and Regards
Pramod