Linux MM : virtual memory address space

Fri Mar 7 12:09:27 EST 2014

Good find Pramod,

I did see that there is also some reference to the AMD x68_64 architecture
page that limits the physical address to be 52-bit max and the virtual
address to be 48-bits[1].

[1] http://developer.amd.com/wordpress/media/2012/10/24593_APM_v2.pdf -
pages 118-120

On Fri, Mar 7, 2014 at 12:14 AM, pramod gurav <pramod.gurav.etc at gmail.com>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140307/4ba2a921/attachment.html 