Fwd: Memory split in 64-bit environment

[Dmitry Filippov]

Every user process in the system has its own virtual address range
that extends from 0 to TASK_SIZE.
The area above (from TASK_SIZE to 2^32 or 2^64 ) is reserved
exclusively for the kernel — and may not be accessed by user
processes. TASK_SIZE is an architecture-specific constant that divides
the address space in a given ratio — in IA-32 systems, for instance,
the address space is divided at 3 GiB so that the virtual address
space for each process is 3 GiB; 1 GiB is available to the kernel
because the total size of the virtual address space is 4 GiB. Although
actual figures differ according to architecture, the general concepts
do not.
This division does not depend on how much RAM is available. As a
result of address space virtualization, each user process thinks it
has 3 GiB of memory. The userspaces of the individual system processes
are totally separate from each other. The kernel space at the top end
of the virtual address space is always the same, regardless of the
process currently executing.
Notice that the picture can be more complicated on 64-bit machines
because these tend to use less than 64 bits to actually manage their
huge principal virtual address space. Instead of 64 bits, they employ
a smaller number, for instance, 42 or 47 bits. Because of this, the
effectively addressable portion of the address space is smaller than
the principal size. However, it is still larger than the amount of RAM
that will ever be present in the machine, and is therefore completely
sufficient. As an advantage, the CPU can save some effort because less
bits are required to manage the effective address space than are
required
to address the complete virtual address space. The virtual address
space will contain holes that are not addressable in principle in such
cases.

hopes this gives high level overview

thanks,
Dmitry


2012/11/2 Adam Lee <adam8157 at gmail.com>:
> On Fri, Nov 02, 2012 at 07:40:11PM +0530, Pritam Bankar wrote:
>> On Fri, Nov 2, 2012 at 4:26 PM, Mulyadi Santosa
>> <mulyadi.santosa at gmail.com> wrote:
>> > Hi :)
>> >
>> > On Fri, Nov 2, 2012 at 5:46 PM, Pritam Bankar
>> > <pritambankar1988 at gmail.com> wrote:
>> >> But I have some questions,
>> >>
>> >> 1. How is memory split up on 64-bit architecture
>> >
>> > in this URL:
>> > http://unix.stackexchange.com/questions/32244/user-kernel-split-in-64bit-linux
>> >
>> > it says user space get 128 TiB...the rest you can read  there :)
>> >
>> >> 2. Can we override this 3:1 split ?
>> >
>> > sure.... just change PAGE_OFFSET if I remember correctly...however,
>> > the effects might be harmful, for example for certain virtualization
>> > since they assume certain address for memory allocation
>> >
>> >> 3. If yes, who can do that user or kernel?
>> >
>> > kernel..for sure..
>>
>> Thanks Mulyadi. I gone through link but there is no explanation. What
>> can be the logic behind kernel space of only 512 MB for 64-bit
>> machines. We have 1GB kernel space in 32-bit architecture so 64-bit
>> should ideally have much more than that.
>
> 1, that 512MB is kernel text mapping(kernel image), not kernel space.
>
> 2, kernel space under x86_64 is 128TB _now_, same as user space.
>
> 3, _now_, the split is 1:1, because address space is large enough.
>
> 4, change PAGE_OFFSET is not enough, _now_, under x86_64, PAGE_OFFSET is
> 0xffff880000000000, the beginning of direct mapping of all phys memory,
> but the beginning of kernel space is 0xffff800000000000, there is a
> guard hole between them.
>
> Please check https://en.wikipedia.org/wiki/X86-64, and the reasons I
> underline _now_ are kernel's current design and
> https://en.wikipedia.org/wiki/X86-64#Canonical_form_addresses
>
> PS, if you can read Chinese(hopeless), check my blog:
> http://adam8157.info/blog/2012/07/linux-x86-64-vm/
>
> --
> Regards,
> Adam Lee
> http://adam8157.info
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies