Hi Dave, Santhosh,<br><br>Thanks for the reply! I was talking about the following paragraph from the reference you provided :<br><br>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<br>
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. <b>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.</b><br>
<br><div class="gmail_quote">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<br>into kernel's portion of virtual address 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.<br>
I am little confused.<br><br>Thanks<br>Vaibhav Jain<br><br>On Mon, Jul 25, 2011 at 5:51 PM, Dave Hylands <span dir="ltr"><<a href="mailto:dhylands@gmail.com">dhylands@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Vaibhav,<br>
<div><div></div><div class="h5"><br>
On Mon, Jul 25, 2011 at 3:17 PM, Vaibhav Jain <<a href="mailto:vjoss197@gmail.com">vjoss197@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> I read a few articles on linux virtual memory management such as this one :<br>
> <a href="http://lwn.net/Articles/75174/" target="_blank">http://lwn.net/Articles/75174/</a><br>
><br>
> which say that earlier linux kernel could only use memory slightly below 1<br>
> GB. They have<br>
> given the reason for it but I am unable to understand.They further describe<br>
> the use of High memory and low memory.<br>
> Could anybody please explain the reason for kernel not being able to use the<br>
> 1 GB completely?<br>
> Also please provide references for high memory and low memory.<br>
<br>
</div></div>My numbers/comments are for the ARM processor, the x86 may be slightly<br>
different.<br>
<br>
The typical configuration for the kernel has addresses from 0x00000000<br>
through 0xC0000000 given to user space (it's actually a small amount<br>
less than 3 GB since modules are loaded in the space just before<br>
0xC0000000).<br>
<br>
That leaves 0xC0000000 to 0xFFFFFFFF for kernel virtual memory (or 1<br>
Gb). Now devices need some I/O space, which takes away from the 1Gb.<br>
<br>
I think what you're calling low memory is kernel logical memory. See<br>
<a href="http://lwn.net/images/pdf/LDD3/ch15.pdf" target="_blank">http://lwn.net/images/pdf/LDD3/ch15.pdf</a> on page 414 (not the 414th<br>
page of the PDF, but the page with 414 printed on the bottom).<br>
<br>
High memory is memory which is not directly accessible by the kernel.<br>
You need to use kmap/kunmap to map the memory into the kernel virtual<br>
memory space. Low memory is always accessible by the kernel.<br>
<br>
So user-mode programs get allocated from high-memory (if high memory<br>
exists) since the kernel doesn't typically need to access the<br>
user-space memory.<br>
<br>
It is possible to set some CONFIG options and have the 3Gb/1Gb split<br>
changed to 2Gb/2Gb or 1Gb/3Gb, but 3Gb/1Gb is the normal default.<br>
<font color="#888888"><br>
--<br>
Dave Hylands<br>
Shuswap, BC, Canada<br>
<a href="http://www.davehylands.com" target="_blank">http://www.davehylands.com</a><br>
</font></blockquote></div><br>