Linux MM : virtual memory address space

Subramaniam Appadodharana c.a.subramaniam at gmail.com
Thu Mar 6 12:48:01 EST 2014


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
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140306/4cebf189/attachment.html 


More information about the Kernelnewbies mailing list