<div dir="ltr">Sergio,<div>        I will try to answer some questions with my limited knowledge. I hope experts will clarify if there are any misconceptions in my understanding.<br><div class="gmail_extra"><br><br><div class="gmail_quote">

On Tue, May 14, 2013 at 12:41 AM, Sergio Andrés Gómez del Real <span dir="ltr">&lt;<a href="mailto:sergio.g.delreal@gmail.com" target="_blank">sergio.g.delreal@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I&#39;ve got some questions regarding this linear to physical address<br>
mapping on x86 architecture; I&#39;m not sure I&#39;ve grassped the whole<br>
thing.<br>
Before asking, I&#39;d like to be sure I understand some basic things about this:<br>
<br>
1. Addresses within the kernel are linked to start at 0xC0000000 so,<br>
that the kernel issues linear addresses starting at gigabyte 3 is<br>
really accomplished at link time through a linker directive.<br>
2. User applications are linked to addresses somewhere at 0x00000000-0xBFFFFFFF.<br>
3. There is a data structure (struct page), immediately following the<br>
kernel image in physical memory. It describes all page frames<br>
available.<br>
4. The kernel creates its own page-relative structures. It maps linear<br>
addresses starting at 0xC0000000 linearly starting at physical address<br>
0x00000000. So, accessing this linear space is equivalent to accessing<br>
physical memory, because the map is linear and the conversion between<br>
linear to physical address is always a constant (0xC0000000)·<br>
5. The last part of the kernel&#39;s linear address space is reserved for<br>
temporarily mapping high memory (is this strictly true?).<br>
<br>
If all of this is true, here are my questions:<br>
<br>
1. The problem of accessing high memory is EXCLUSIVE to the kernel,<br>
right? It doesn&#39;t affect user-space applications, because it&#39;s linear<br>
address, 0x00000000-0xBFFFFFFF, can be mapped anywhere in physical<br>
memory, by just writing the high-memory address to the appropiate page<br>
tables. Is this right?<br></blockquote><div> </div><div style>Yeah. Its exclusive to the kernel. Consider that we have a 32 bit system with 4GB physical memory and we have a 3:1 split. Kernel must be able to access all the physical memory-4GB-but it has only 1GB of virtual address space. User process&#39;s on the other hand can only access maximum 3GB (hypothetical) of physical memory and has an virtual address space of 3GB of size.  Now coming back to the problem of the Kernel, very old kernels made use of static mapping to the address space. So with 1GB of address space, they could only access 1GB of physical memory. The solution the Kernel developers  found was to use dynamic mappings. That is use some area in the Kernel virtual addresses to dynamically map to  higher memory.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. When user applications allocates memory, the kernel must allocate<br>
virtual memory and physical memory, right? For example, the kernel<br>
would first allocate some linear address from the processes&#39; address<br>
space, and then find some suitable page frames where to map this<br>
linear address. It would just write to the appropiate page tables;<br>
specifically, the page frames can come from low memory or high memory,<br>
i.e the high memory problem does not affect user-space physical memory<br>
allocations. Is this entirely correct?<br>
3. Is physical memory allocated to user-space generally satisfied from<br>
high memory?<br></blockquote><div><br></div><div style>In a system with  an installed physical memory of 896 MB does not have any high memory(Applicable to x86 systems only). So I feel that assumption is wrong.</div><div style>

<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. When does the kernel allocate pages from high memory to itself?<br>
<br>
Thanks in advance to anyone who replies.<br>
<div><div class="h5"><br>
On 5/13/13, Prabhu nath &lt;<a href="mailto:gprabhunath@gmail.com">gprabhunath@gmail.com</a>&gt; wrote:<br>
&gt; Is this is a question that popped up to your mind arbitrarily or do you<br>
&gt; have a specific system at hand which triggered you to ponder over the<br>
&gt; design of the kernel ? I felt the answer to this question is not straight<br>
&gt; forward but is multi faceted and to be discussed in a specific context.<br>
&gt;<br>
&gt;<br>
&gt; On Sat, May 11, 2013 at 9:02 AM, Paul Davies C<br>
&gt; &lt;<a href="mailto:pauldaviesc@gmail.com">pauldaviesc@gmail.com</a>&gt;wrote:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; In a system with 3:1 split, the ZONE_NORMAL with a size of 896MB is<br>
&gt;&gt; permanently mapped to the kernel address space.This leaves a 128MB free<br>
&gt;&gt; space in the Kernel address space and according to my understanding, the<br>
&gt;&gt; ZONE_HIGHMEM pages are mapped temporarily to this 128MB part. If the<br>
&gt;&gt; system<br>
&gt;&gt; actually had a 4GB physical memory you will be mapping(not smultaneously)<br>
&gt;&gt; the HIHGMEM part- which is roughly 3.2GB - to this 128MB part. If that<br>
&gt;&gt; was<br>
&gt;&gt; the case Kernel would have to frequently access HIHGMEM which implicates<br>
&gt;&gt; a<br>
&gt;&gt; frequent change in temporaty mapping and that in my view is a penalty. So<br>
&gt;&gt; what was the reason why ZONE_NORMAL fixed at 896MB and not something<br>
&gt;&gt; really<br>
&gt;&gt; lower?<br>
&gt;&gt;<br>
&gt;&gt; --<br>
</div></div>&gt;&gt; *Regards,*<br>
&gt;&gt; *Paul Davies C*<br>
<div class="HOEnZb"><div class="h5">&gt;&gt; <a href="http://vivafoss.blogspot.com" target="_blank">vivafoss.blogspot.com</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; --<br>
&gt; Regards,<br>
&gt; Prabhunath G<br>
&gt; Linux Trainer<br>
&gt; Bangalore<br>
&gt;<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><font face="&#39;arial narrow&#39;, sans-serif" color="#C0C0C0"><b>Regards,</b></font></div><div><font face="&#39;arial narrow&#39;, sans-serif" color="#C0C0C0"><b>Paul Davies C</b></font></div>

<a href="http://vivafoss.blogspot.com" target="_blank">vivafoss.blogspot.com</a>
</div></div></div>