Hi Telenn,<br><br><div class="gmail_quote">On Fri, Oct 19, 2012 at 3:03 PM, telenn barz <span dir="ltr">&lt;<a href="mailto:telenn.barz@gmail.com" target="_blank">telenn.barz@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">

Hi all,<br><br>This a vast topic. But I believe it&#39;s worthwhile exposing in greater detail the &quot;Why this design has been chosen ?&quot;, before the &quot;How this design has been implemented ?&quot;. And I think this is a common lack (or at least not enough developed) in documentations, even in the more outstanding of them.<br>


 <br>Let&#39;s try to be more precise :<br><br>A] About the direct mapping of the first 896MB of the virtual kernel space to the first 896MB of the physical memory<br><br>Thus the kernel is able to handle a big virtual memory area mapped to a zone of contiguous physical addresses. This is a need for some peripheral devices which are unable to deal with paged memory. So all right, I can understand that (ref: &quot;<a href="http://lwn.net/Articles/211505/" target="_blank">Avoiding - and fixing - memory fragmentation</a>&quot; at <a href="http://lwn.net" target="_blank">lwn.net</a>). But this article also says this is required for large kernel data structures... <br>


<br>Q: ...Here I don&#39;t get the point : why wouldn&#39;t it be possible for the kernel to handle its structures through paged memory not necessarily physically contiguous ?<br><br>In the bible &quot;Understanding the Linux Kernel&quot; third edition, at section &quot;8.3 Non-contiguous Memory Area Management&quot; it is written : &quot;[...] it is preferable to map areas into sets of contiguous page frames, thus making better use of the cache and achieving lower average memory access times&quot;.<br>


<br>Q: Is this assertion still valid on modern architecture ? Can please someone explain in further detail the theory behind it, or point me to relevant documentations ?<br><br>Q: Do you see any other reason for this physically-contiguous memory requirement ?<br>


<br>B] About the 3G/1G split of process&#39; virtual address space on 32-bit architecture<br><br>The article &quot;<a href="http://lwn.net/Articles/75174/" target="_blank">Virtual Memory I: the problem</a>&quot; at <a href="http://lwn.net" target="_blank">lwn.net</a> says it has to see with the TLB : by sharing the process&#39; virtual space, we also share the TLB and thus we avoid a costly TLB flush at each user-space to kernel-space switch. The article invokes this reason of degradation performance when talking about the 4G/4G split patch (from Ingo Molnar).<br>


<br>Q: In the 4G/4G split case, I don&#39;t see why we have to necessarily flush the TLB when switching from user-space to kernel-space ? Why the TLB couldn&#39;t be shared across one user-space to kernel-space switch, and be flushed only every two switches ?<br>

</blockquote><div><br>In 4G/4G split, kernel space(KS) and user space(US) both have 4GB address space. So there can be a same virtual address present in KS &amp; US which corresponds to two different physical addressess.<br>

When switching from US to KS or vice versa, the pointer to page table has to be changed in the MMU. So TLB which is just a cache for the page tables has to be flushed aswell.<br><br>thanks,<br>Arun<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>The TLB is small, Ok... but is it really a matter of TLB size ? I mean the kernel can rely on big pages for backing its virtual space : this is already the case for Intel Pentium (ref: &quot;Understanding the Linux Kernel&quot; third edition) which uses 4MB pages, or for Freescale e500v2/e500mc family which uses 256MB pages. On this architecture, if it had to map 4GB of physical memory, it could even use a single huge page, thus occupying a single page table entry, and so a single TLB entry...<br>


<br>Thanks to anyone for bringing a gentle breeze of cleverness on my cloudy brain,<br>Telenn<br>
<br>_______________________________________________<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>
<br></blockquote></div><br>