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 <[email protected]>wrote: > On Thu, Mar 6, 2014 at 11:18 PM, Subramaniam Appadodharana > <[email protected]> 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 <[email protected]> > wrote: > >> > >> > -----Original Message----- > >> > From: pramod gurav [mailto:[email protected]] > >> > 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 <[email protected]> > >> > wrote: > >> > > > >> > > > >> > > > >> > > > >> > > From: [email protected] > >> > > [mailto:[email protected]] 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 > >> > > <[email protected]> > >> > > 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@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 > >> [email protected] > >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > > > > -- > Thanks and Regards > Pramod >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
