Hi Vaibhav, On Mon, Jul 25, 2011 at 9:40 PM, Vaibhav Jain <vjoss197@gmail.com> wrote:
Hi Dave, Santhosh,
Thanks for the reply! I was talking about the following paragraph from the reference you provided :
The kernel (on the x86 architecture, in the default configuration) splits the 4-GB virtual address space between user-space and the kernel; the same set of mappings is used in both contexts. A typical split dedicates 3 GB to user space, and 1 GB for kernel space.* The kernel’s code and data structures must fit into that space, but the biggest consumer of kernel address space is virtual mappings for physical memory. The kernel cannot directly manipulate memory that is not mapped into the kernel’s address space. The kernel, in other words, needs its own virtual address for any memory it must touch directly. Thus, for many years, the maximum amount of physical memory that could be handled by the kernel was the amount that could be mapped into the kernel’s portion of the virtual address space, minus the space needed for the kernel code itself. As a result, x86-based Linux systems could work with a maximum of a little under 1 GB of physical memory.
I am still not clear about the sentences in bold. Why is the space needed for kernel code subtracted from the amount that could be mapped into kernel's portion of virtual address space ?
Well the kernel code needs to run from the kernel virtual space.
Also , what difference does the fact - "biggest consumer of kernel address space is virtual mappings for physical memory" make in the amount of memory that can be handled by the kernel.
In order to access memory you need to have MMU tables. These MMU tables are what maps the virrtual to physical memory. MMU entries are needed for every single page. I don't quite think that they take up a huge amount of memory. There is also a page structure for every page of physical memory. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com