Hi Sergio,<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"><<a href="mailto:sergio.g.delreal@gmail.com" target="_blank">sergio.g.delreal@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've got some questions regarding this linear to physical address<br>
mapping on x86 architecture; I'm not sure I've grassped the whole<br>
thing.<br>
Before asking, I'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></blockquote><div><br></div><div>Physical address may not be always 0x0000_0000. It can be mapped any where.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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'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't affect user-space applications, because it'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>
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' 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>Yes. High mem is the first priority.</div><div><br></div><div>thanks,</div><div>Arun</div><div> </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 <<a href="mailto:gprabhunath@gmail.com">gprabhunath@gmail.com</a>> wrote:<br>
> Is this is a question that popped up to your mind arbitrarily or do you<br>
> have a specific system at hand which triggered you to ponder over the<br>
> design of the kernel ? I felt the answer to this question is not straight<br>
> forward but is multi faceted and to be discussed in a specific context.<br>
><br>
><br>
> On Sat, May 11, 2013 at 9:02 AM, Paul Davies C<br>
> <<a href="mailto:pauldaviesc@gmail.com">pauldaviesc@gmail.com</a>>wrote:<br>
><br>
>><br>
>> In a system with 3:1 split, the ZONE_NORMAL with a size of 896MB is<br>
>> permanently mapped to the kernel address space.This leaves a 128MB free<br>
>> space in the Kernel address space and according to my understanding, the<br>
>> ZONE_HIGHMEM pages are mapped temporarily to this 128MB part. If the<br>
>> system<br>
>> actually had a 4GB physical memory you will be mapping(not smultaneously)<br>
>> the HIHGMEM part- which is roughly 3.2GB - to this 128MB part. If that<br>
>> was<br>
>> the case Kernel would have to frequently access HIHGMEM which implicates<br>
>> a<br>
>> frequent change in temporaty mapping and that in my view is a penalty. So<br>
>> what was the reason why ZONE_NORMAL fixed at 896MB and not something<br>
>> really<br>
>> lower?<br>
>><br>
>> --<br>
</div></div>>> *Regards,*<br>
>> *Paul Davies C*<br>
<div class="im">>> <a href="http://vivafoss.blogspot.com" target="_blank">vivafoss.blogspot.com</a><br>
>><br>
>><br>
> --<br>
> Regards,<br>
> Prabhunath G<br>
> Linux Trainer<br>
> Bangalore<br>
><br>
<br>
</div>_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</blockquote></div><br>