<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://kerneltrap.org"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>KernelTrap - virtual compound page</title>
 <link>http://kerneltrap.org/taxonomy/term/1027/0</link>
 <description></description>
 <language>en-local</language>
<item>
 <title>Virtual Compound Pages</title>
 <link>http://kerneltrap.org/Linux/Virtual_Compound_Pages</link>
 <description>&lt;div class=&quot;taxonomy-images&quot;&gt;&lt;a href=&quot;/news/linux&quot; class=&quot;taxonomy-image-links&quot;&gt;&lt;img src=&quot;http://kerneltrap.org/files/category_pictures/K-Linux.gif&quot; alt=&quot;Linux news&quot; title=&quot;Linux news&quot;  width=&quot;75&quot; height=&quot;75&quot; /&gt;&lt;/a&gt;&lt;/div&gt;&lt;!-- google_ad_section_start --&gt;&lt;p&gt;&quot;&lt;i&gt;Allocations of larger pages are not reliable in Linux. If larger pages have to be allocated then one faces various choices of allowing graceful fallback or using vmalloc with a performance penalty due to the use of a page table,&lt;/i&gt;&quot; began Christoph Lameter, describing the third version of his virtual compound page support patchset.  He continued, &quot;&lt;i&gt;a virtual compound allocation means that there will be first of all an attempt to satisfy the request with physically contiguous memory. If that is not possible then a virtually contiguous memory will be created.&lt;/i&gt;&quot;  Christopher proposed two advantages:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;1. Current uses of vmalloc can be converted to allocate virtual compounds instead. In most cases physically contiguous memory can be used which avoids the vmalloc performance penalty.  2. Uses of higher order allocations (stacks, buffers etc) can be converted to use virtual compounds instead. Physically contiguous memory will still be used for those higher order allocs in general but the system can degrade to the use of vmalloc should memory become heavily fragmented.&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://kerneltrap.org/Linux/Virtual_Compound_Pages&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://kerneltrap.org/Linux/Virtual_Compound_Pages#comments</comments>
 <category domain="http://kerneltrap.org/Christoph_Lameter">Christoph Lameter</category>
 <category domain="http://kerneltrap.org/Linux">Linux</category>
 <category domain="http://kerneltrap.org/memory">memory</category>
 <category domain="http://kerneltrap.org/taxonomy/term/1027">virtual compound page</category>
 <category domain="http://kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Fri, 21 Mar 2008 23:53:07 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">15824 at http://kerneltrap.org</guid>
</item>
<item>
 <title>Virtual Compound Page Support</title>
 <link>http://kerneltrap.org/Linux/Virtual_Compound_Page_Support</link>
 <description>&lt;div class=&quot;taxonomy-images&quot;&gt;&lt;a href=&quot;/news/linux&quot; class=&quot;taxonomy-image-links&quot;&gt;&lt;img src=&quot;http://kerneltrap.org/files/category_pictures/K-Linux.gif&quot; alt=&quot;Linux news&quot; title=&quot;Linux news&quot;  width=&quot;75&quot; height=&quot;75&quot; /&gt;&lt;/a&gt;&lt;/div&gt;&lt;!-- google_ad_section_start --&gt;&lt;p&gt;&quot;&lt;i&gt;Currently there is a strong tendency to avoid larger page allocations in the kernel because of past fragmentation issues and the current defragmentation methods are still evolving,&lt;/i&gt;&quot; Christoph Lameter began, posting the first version of his &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-fsdevel/2007/9/25/322501&quot;&gt;Virtual Compound Page Support patches&lt;/a&gt;, a followup to his &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2007/9/18/263288&quot;&gt