Fwd: Memory split in 64-bit environment
On Fri, Nov 2, 2012 at 4:26 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi :)
On Fri, Nov 2, 2012 at 5:46 PM, Pritam Bankar <pritambankar1988@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-lin...
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..
-- regards,
Mulyadi Santosa Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
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. Thanks Pritam Bankar
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@gmail.com> wrote:
Hi :)
On Fri, Nov 2, 2012 at 5:46 PM, Pritam Bankar <pritambankar1988@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-lin...
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
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@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@gmail.com> wrote:
Hi :)
On Fri, Nov 2, 2012 at 5:46 PM, Pritam Bankar <pritambankar1988@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-lin...
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Thanks Dmitry and Adam. Great explanation...! On Fri, Nov 2, 2012 at 9:20 PM, Dmitry Filippov <filippovd20@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@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@gmail.com> wrote:
Hi :)
On Fri, Nov 2, 2012 at 5:46 PM, Pritam Bankar <pritambankar1988@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-lin...
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Pritam Bankar
participants (3)
-
Adam Lee -
Dmitry Filippov -
Pritam Bankar