* Linux MM : virtual memory address space
@ 2014-03-03 18:22 priyaranjan
2014-03-03 18:41 ` Jeff Haran
2014-03-04 7:33 ` pramod gurav
0 siblings, 2 replies; 9+ messages in thread
From: priyaranjan @ 2014-03-03 18:22 UTC (permalink / raw
To: kernelnewbies
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140303/dde6cd4f/attachment.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Linux MM : virtual memory address space
2014-03-03 18:22 Linux MM : virtual memory address space priyaranjan
@ 2014-03-03 18:41 ` Jeff Haran
2014-03-04 7:33 ` pramod gurav
1 sibling, 0 replies; 9+ messages in thread
From: Jeff Haran @ 2014-03-03 18:41 UTC (permalink / raw
To: kernelnewbies
From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces at kernelnewbies.org] On Behalf Of priyaranjan
Sent: Monday, March 03, 2014 10:22 AM
To: Linux Kernel List
Subject: Linux MM : virtual memory address space
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
Try Documentation/x86/x86_64/mm.txt in the kernel sources, though my recent investigation leads me to believe that it is not entirely accurate.
Jeff Haran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140303/2626ddb3/attachment-0001.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Linux MM : virtual memory address space
2014-03-03 18:22 Linux MM : virtual memory address space priyaranjan
2014-03-03 18:41 ` Jeff Haran
@ 2014-03-04 7:33 ` pramod gurav
2014-03-04 19:09 ` Jeff Haran
1 sibling, 1 reply; 9+ messages in thread
From: pramod gurav @ 2014-03-04 7:33 UTC (permalink / raw
To: kernelnewbies
On Mon, Mar 3, 2014 at 11:52 PM, priyaranjan <priyaranjan45678@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. This virtual
space will still be very large (256 TB) and hence the user/kernel split is
1:1 (128TB:128TB). And as suggested in link it is very unlikely that you
will have such a huge RAM(more than 128TB) installed on any machine there
is no concept of HIGHMEM.
Hope this clears the air a bit.
>
> _______________________________________________
> 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/20140304/45ff1e36/attachment.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Linux MM : virtual memory address space
2014-03-04 7:33 ` pramod gurav
@ 2014-03-04 19:09 ` Jeff Haran
2014-03-06 8:56 ` pramod gurav
0 siblings, 1 reply; 9+ messages in thread
From: Jeff Haran @ 2014-03-04 19:09 UTC (permalink / raw
To: kernelnewbies
From: kernelnewbies-bounces@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<mailto:priyaranjan45678@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
This virtual space will still be very large (256 TB) and hence the user/kernel split is 1:1 (128TB:128TB). And as suggested in link it is very unlikely that you will have such a huge RAM(more than 128TB) installed on any machine there is no concept of HIGHMEM.
Hope this clears the air a bit.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org<mailto:Kernelnewbies@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/20140304/3b026e9c/attachment-0001.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Linux MM : virtual memory address space
2014-03-04 19:09 ` Jeff Haran
@ 2014-03-06 8:56 ` pramod gurav
2014-03-06 17:13 ` Jeff Haran
0 siblings, 1 reply; 9+ messages in thread
From: pramod gurav @ 2014-03-06 8:56 UTC (permalink / raw
To: kernelnewbies
On Wed, Mar 5, 2014 at 12:39 AM, Jeff Haran <Jeff.Haran@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@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. The writer of the blog has
done some wrong manipulations. The user space addresses are correct.
Kernel Space address raneg has to be: 0x0000800000000000 to
0x0000ffffffffffff.
>
>
>
> This virtual space will still be very large (256 TB) and hence the
> user/kernel split is 1:1 (128TB:128TB). And as suggested in link it is very
> unlikely that you will have such a huge RAM(more than 128TB) installed on
> any machine there is no concept of HIGHMEM.
>
>
>
> Hope this clears the air a bit.
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
>
>
> --
> Thanks and Regards
> Pramod
--
Thanks and Regards
Pramod
^ permalink raw reply [flat|nested] 9+ messages in thread
* Linux MM : virtual memory address space
2014-03-06 8:56 ` pramod gurav
@ 2014-03-06 17:13 ` Jeff Haran
2014-03-06 17:48 ` Subramaniam Appadodharana
0 siblings, 1 reply; 9+ messages in thread
From: Jeff Haran @ 2014-03-06 17:13 UTC (permalink / raw
To: kernelnewbies
> -----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@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@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Linux MM : virtual memory address space
2014-03-06 17:13 ` Jeff Haran
@ 2014-03-06 17:48 ` Subramaniam Appadodharana
2014-03-07 6:14 ` pramod gurav
0 siblings, 1 reply; 9+ messages in thread
From: Subramaniam Appadodharana @ 2014-03-06 17:48 UTC (permalink / raw
To: kernelnewbies
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@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@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Linux MM : virtual memory address space
2014-03-06 17:48 ` Subramaniam Appadodharana
@ 2014-03-07 6:14 ` pramod gurav
2014-03-07 17:09 ` Subramaniam Appadodharana
0 siblings, 1 reply; 9+ messages in thread
From: pramod gurav @ 2014-03-07 6:14 UTC (permalink / raw
To: kernelnewbies
On Thu, Mar 6, 2014 at 11:18 PM, Subramaniam Appadodharana
<c.a.subramaniam@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@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@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@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Linux MM : virtual memory address space
2014-03-07 6:14 ` pramod gurav
@ 2014-03-07 17:09 ` Subramaniam Appadodharana
0 siblings, 0 replies; 9+ messages in thread
From: Subramaniam Appadodharana @ 2014-03-07 17:09 UTC (permalink / raw
To: kernelnewbies
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@gmail.com>wrote:
> On Thu, Mar 6, 2014 at 11:18 PM, Subramaniam Appadodharana
> <c.a.subramaniam@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@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@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@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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-03-07 17:09 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-03 18:22 Linux MM : virtual memory address space priyaranjan
2014-03-03 18:41 ` Jeff Haran
2014-03-04 7:33 ` pramod gurav
2014-03-04 19:09 ` Jeff Haran
2014-03-06 8:56 ` pramod gurav
2014-03-06 17:13 ` Jeff Haran
2014-03-06 17:48 ` Subramaniam Appadodharana
2014-03-07 6:14 ` pramod gurav
2014-03-07 17:09 ` Subramaniam Appadodharana
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.