<div dir="ltr">Good find Pramod,<div><br></div><div>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]. </div>
<div class="gmail_extra"><br>[1] <a href="http://developer.amd.com/wordpress/media/2012/10/24593_APM_v2.pdf">http://developer.amd.com/wordpress/media/2012/10/24593_APM_v2.pdf</a> - pages 118-120</div><div class="gmail_extra">
<br><div class="gmail_quote">On Fri, Mar 7, 2014 at 12:14 AM, pramod gurav <span dir="ltr"><<a href="mailto:pramod.gurav.etc@gmail.com" target="_blank">pramod.gurav.etc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">On Thu, Mar 6, 2014 at 11:18 PM, Subramaniam Appadodharana<br>
<<a href="mailto:c.a.subramaniam@gmail.com">c.a.subramaniam@gmail.com</a>> wrote:<br>
> Jeff/Pramod,<br>
><br>
> I think what Pramod mentioned is partly right. However, I do not have more<br>
> info on that yet. Will get back after some more digging in. For kernel<br>
> memory<br>
> addresses you can do,<br>
><br>
> sudo cat /proc/vmallocinfo<br>
><br>
> This is in line with what Jeff mentioned. I will check why the upper 16 bits<br>
> are set to 1.<br>
><br>
><br>
><br>
> On Thu, Mar 6, 2014 at 11:13 AM, Jeff Haran <<a href="mailto:Jeff.Haran@citrix.com">Jeff.Haran@citrix.com</a>> wrote:<br>
>><br>
>> > -----Original Message-----<br>
>> > From: pramod gurav [mailto:<a href="mailto:pramod.gurav.etc@gmail.com">pramod.gurav.etc@gmail.com</a>]<br>
>> > Sent: Thursday, March 06, 2014 12:56 AM<br>
>> > To: Jeff Haran<br>
>> > Cc: priyaranjan; kernelnewbies<br>
>> > Subject: Re: Linux MM : virtual memory address space<br>
>> ><br>
>> > On Wed, Mar 5, 2014 at 12:39 AM, Jeff Haran <<a href="mailto:Jeff.Haran@citrix.com">Jeff.Haran@citrix.com</a>><br>
>> > wrote:<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > From: <a href="mailto:kernelnewbies-bounces@kernelnewbies.org">kernelnewbies-bounces@kernelnewbies.org</a><br>
>> > > [mailto:<a href="mailto:kernelnewbies-bounces@kernelnewbies.org">kernelnewbies-bounces@kernelnewbies.org</a>] On Behalf Of pramod<br>
>> > > gurav<br>
>> > > Sent: Monday, March 03, 2014 11:33 PM<br>
>> > > To: priyaranjan<br>
>> > > Cc: kernelnewbies<br>
>> > > Subject: Re: Linux MM : virtual memory address space<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > On Mon, Mar 3, 2014 at 11:52 PM, priyaranjan<br>
>> > > <<a href="mailto:priyaranjan45678@gmail.com">priyaranjan45678@gmail.com</a>><br>
>> > > wrote:<br>
>> > ><br>
>> > > I was going through <a href="http://linux-mm.org/HighMemory" target="_blank">http://linux-mm.org/HighMemory</a><br>
>> > ><br>
>> > ><br>
>> > > "Currently the 32 bit x86 architecture is the most popular type of<br>
>> > > computer.<br>
>> > > In this architecture, traditionally the Linux kernel has split the 4GB<br>
>> > > of<br>
>> > > virtual memory address space into 3GB for user programs and 1GB for<br>
>> > > the<br>
>> > > kernel"<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > What about 64-bit system? Where does the code lie in linux kernel for<br>
>> > > the<br>
>> > > check?<br>
>> > ><br>
>> > > Is there any latest and updated memory management documentation for<br>
>> > > Linux<br>
>> > > kernel?<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > Regards,<br>
>> > ><br>
>> > > Priyaranjan<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > Priyaranjan,<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > As below link suggests:<br>
>> > ><br>
>> > > <a href="http://users.nccs.gov/~fwang2/linux/lk_addressing.txt" target="_blank">http://users.nccs.gov/~fwang2/linux/lk_addressing.txt</a><br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > Also read this blog written in chinese:<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > <a href="http://adam8157.info/blog/2012/07/linux-x86-64-vm/" target="_blank">http://adam8157.info/blog/2012/07/linux-x86-64-vm/</a><br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > on 64 bit arch the virtual address space is huge (2 to thr power of<br>
>> > > 64). So<br>
>> > > the overhead of translating the virtual addresses will be high. TO<br>
>> > > avoid<br>
>> > > this only lower 48 bits are used to form virtual addresses.<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > I believe this statement about only the lower 48 bits being used it<br>
>> > > not<br>
>> > > correct. That would imply that the upper 16 bits of all virtual<br>
>> > > addresses on<br>
>> > > x86_64 would be the same, which is clearly not the case since the<br>
>> > > upper 16<br>
>> > > bits of user space vas are all 0s yet the upper 16 bits of kernel<br>
>> > > space vas<br>
>> > > are all 1s.<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > Jeff Haran<br>
>> > ><br>
>> > ><br>
>> > Hi Jeff,<br>
>> > Just noticed a line in /proc/cpuinfo on my 64 bit linux Machine which<br>
>> > is:<br>
>> ><br>
>> > --> address sizes : 36 bits physical, 48 bits virtual<br>
>> ><br>
>> > This should confirm the statement that, only lower 48 bits are used<br>
>> > for virtual address space on a 64 it arch.<br>
>> > And about upper 16 bits in kernel being 1s in the address range shown<br>
>> > in the link, I think they are not correct.<br>
>><br>
>> All I can suggest is that you take a kernel and modify it to prink() the<br>
>> virtual address of some kernel data structure (or write a module to do the<br>
>> same) and see for yourself. At least on the x86_64 systems I use, the<br>
>> address of for example a struct sk_buff, which is allocated from a kmem<br>
>> cache, is in the upper end of the 64 bit address range. The top 16 bits are<br>
>> all 1s. Always. This is running recent Redhat EL6, but I believe the same<br>
>> will be true for kernels from <a href="http://kernel.org" target="_blank">kernel.org</a>.<br>
>><br>
>> Jeff Haran<br>
>><br>
>><br>
<br>
</div></div>Jeff, Subbu,<br>
<br>
Please refer to the wiki page here,<br>
<a href="http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details" target="_blank">http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details</a><br>
<br>
This talks about something like canonical form of addresses. A quote<br>
in the page says, " Canonical form addresses run from 0 through<br>
00007FFF'FFFFFFFF, and from FFFF8000'00000000 through<br>
FFFFFFFF'FFFFFFFF, for a total of 256 TB of usable virtual address<br>
space".<br>
<br>
Possibly this is the reason we are getting all upper 16 bits in 1s for<br>
kernel virtual address space. which means kernel virtual address space<br>
range on 64 bit arch is FFFF8000'00000000 - FFFFFFFF'FFFFFFFF which<br>
higher part of 256 TB vurtual address space. But for user space it is<br>
lower half of 256TB. You need not write a code for this. You ca just<br>
cat memory maps of any process running in system. Example:<br>
<br>
gpramod@localhost:$ sudo cat /proc/1/maps<br>
<br>
First part is user process mapped in user space virtual address space:<br>
7faf6de70000-7faf6de7c000 r-xp 00000000 08:05 2102384<br>
/lib/x86_64-linux-gnu/<a href="http://libnss_files-2.15.so" target="_blank">libnss_files-2.15.so</a><br>
7faf6de7c000-7faf6e07b000 ---p 0000c000 08:05 2102384<br>
/lib/x86_64-linux-gnu/<a href="http://libnss_files-2.15.so" target="_blank">libnss_files-2.15.so</a><br>
7faf6e07b000-7faf6e07c000 r--p 0000b000 08:05 2102384<br>
/lib/x86_64-linux-gnu/<a href="http://libnss_files-2.15.so" target="_blank">libnss_files-2.15.so</a><br>
7faf6e07c000-7faf6e07d000 rw-p 0000c000 08:05 2102384<br>
/lib/x86_64-linux-gnu/<a href="http://libnss_files-2.15.so" target="_blank">libnss_files-2.15.so</a><br>
7faf6e07d000-7faf6e087000 r-xp 00000000 08:05 2102388<br>
/lib/x86_64-linux-gnu/<a href="http://libnss_nis-2.15.so" target="_blank">libnss_nis-2.15.so</a><br>
7faf6e087000-7faf6e287000 ---p 0000a000 08:05 2102388<br>
/lib/x86_64-linux-gnu/<a href="http://libnss_nis-2.15.so" target="_blank">libnss_nis-2.15.so</a><br>
7faf6e287000-7faf6e288000 r--p 0000a000 08:05 2102388<br>
/lib/x86_64-linux-gnu/<a href="http://libnss_nis-2.15.so" target="_blank">libnss_nis-2.15.so</a><br>
7faf6e288000-7faf6e289000 rw-p 0000b000 08:05 2102388<br>
/lib/x86_64-linux-gnu/<a href="http://libnss_nis-2.15.so" target="_blank">libnss_nis-2.15.so</a><br>
7faf6e289000-7faf6e2a0000 r-xp 00000000 08:05 2102400<br>
/lib/x86_64-linux-gnu/<a href="http://libnsl-2.15.so" target="_blank">libnsl-2.15.so</a><br>
.<br>
.<br>
.<br>
.<br>
.<br>
.<br>
(Last part is Kernel process (system calls) mapped in Kernel virtual<br>
address space:)<br>
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0<br>
[vsyscall]<br>
<br>
So what you said is correct about the upper 16 bits being 1s. It also<br>
verifies the "48 bits for virtual address space" theory as well.<br>
<div class="im"><br>
>> _______________________________________________<br>
>> Kernelnewbies mailing list<br>
>> <a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
>> <a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
><br>
><br>
<br>
<br>
<br>
</div><div class=""><div class="h5">--<br>
Thanks and Regards<br>
Pramod<br>
</div></div></blockquote></div><br></div></div>