Thanks Dmitry and Adam. Great explanation...! On Fri, Nov 2, 2012 at 9:20 PM, Dmitry Filippov <filippovd20@xxxxxxxxx> 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@xxxxxxxxx>: >> 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@xxxxxxxxx> wrote: >>> > Hi :) >>> > >>> > On Fri, Nov 2, 2012 at 5:46 PM, Pritam Bankar >>> > <pritambankar1988@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Pritam Bankar _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
