Query regarding kernel memory

[Dave Hylands]

Hi Vaibhav,

On Mon, Jul 25, 2011 at 9:40 PM, Vaibhav Jain <vjoss197 at 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