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 > > > _______________________________________________ > Kernelnewbies mailing list > [email protected] > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
