Fwd: Memory split in 64-bit environment

[Pritam Bankar]

Thanks Dmitry and Adam. Great explanation...!

On Fri, Nov 2, 2012 at 9:20 PM, Dmitry Filippov <filippovd20 at gmail.com> wrote:
> 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



-- 

Pritam Bankar