<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.kerneltrap.org"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>KernelTrap - RAM</title>
 <link>http://www.kerneltrap.org/taxonomy/term/477/0</link>
 <description></description>
 <language>en-local</language>
<item>
 <title>Linux: Memory Compaction </title>
 <link>http://www.kerneltrap.org/Linux/Memory_Compaction</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;&lt;a href=&quot;http://kerneltrap.org/Mel_Gorman&quot;&gt;Mel Gorman&lt;/a&gt; posted the &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2010/4/2/4554850&quot;&gt;seventh version&lt;/a&gt; of his Memory Compaction patches asking, &quot;&lt;i&gt;are there any further obstacles to merging?&lt;/i&gt;&quot;  The patches, &lt;a href=&quot;http://kerneltrap.org/node/8292&quot;&gt;first posted&lt;/a&gt; in May of 2007, provide a mechanism for moving GFP_MOVABLE pages into a smaller number of pageblocks, reducing externally fragmented memory.  Mel explains that &#039;compaction&#039; is another method of defragmenting memory, &quot;&lt;i&gt;for example, lumpy reclaim is a form of defragmentation as was slub &#039;defragmentation&#039; (really a form of targeted reclaim). Hence, this is called &#039;compaction&#039; to distinguish it from other forms of defragmentation.&lt;/i&gt;&quot;&lt;/p&gt;
&lt;p&gt;The core compaction patch explains that memory is compacted in a zone by relocating movable pages towards the end of the zone:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;A single compaction run involves a migration scanner and a free scanner.  Both scanners operate on pageblock-sized areas in the zone. The migration scanner starts at the bottom of the zone and searches for all movable pages within each area, isolating them onto a private list called migratelist.  The free scanner starts at the top of the zone and searches for suitable areas and consumes the free pages within making them available for the migration scanner. The pages isolated for migration are then migrated to the newly isolated free pages.&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://www.kerneltrap.org/Linux/Memory_Compaction&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.kerneltrap.org/Linux/Memory_Compaction#comments</comments>
 <category domain="http://www.kerneltrap.org/taxonomy/term/251">compacting memory</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/866">defragmentation</category>
 <category domain="http://www.kerneltrap.org/Linux">Linux</category>
 <category domain="http://www.kerneltrap.org/mel_gorman">Mel Gorman</category>
 <category domain="http://www.kerneltrap.org/memory">memory</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/583">patch</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/477">RAM</category>
 <category domain="http://www.kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Sat, 03 Apr 2010 00:11:38 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">55793 at http://www.kerneltrap.org</guid>
</item>
<item>
 <title>Keeping Ramdisk Pages Dirty</title>
 <link>http://www.kerneltrap.org/Linux/Keeping_Ramdisk_Pages_Dirty</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;We have seen ramdisk based install systems, where some pages of mapped libraries and programs were suddendly zeroed under memory pressure.  This should not happen, as the ramdisk avoids freeing its pages by keeping them dirty all the time,&lt;/i&gt;&quot; Christian Borntraeger began, explaining the need for his &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2007/10/9/333041&quot;&gt;small patch to the ramdisk driver&lt;/a&gt;.  He continued, &quot;&lt;i&gt;it turns out that there is a case, where the VM makes a ramdisk page clean, without telling the ramdisk driver. On memory pressure shrink_zone runs and it starts to run shrink_active_list.  There is a check for buffer_heads_over_limit, and if true, pagevec_strip is called. pagevec_strip calls try_to_release_page. If the mapping has no releasepage callback, try_to_free_buffers is called. try_to_free_buffers has now a special logic for some file systems to make a dirty page clean, if all buffers are clean. Thats what happened in our test case.&lt;/i&gt;&quot;&lt;/p&gt;
&lt;p&gt;He provided two methods for duplicating the reported problem, &quot;&lt;i&gt;you have to make buffer_heads_over_limit true&lt;/i&gt;&quot;  This is done by either lowering &lt;code&gt;max_buffer_heads&lt;/code&gt; or having a system with lots of high memory.  &quot;&lt;i&gt;The solution is to provide a noop-releasepage callback for the ramdisk driver. This avoids try_to_free_buffers for ramdisk pages.&lt;/i&gt;&quot;&lt;/p&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://www.kerneltrap.org/Linux/Keeping_Ramdisk_Pages_Dirty&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.kerneltrap.org/Linux/Keeping_Ramdisk_Pages_Dirty#comments</comments>
 <category domain="http://www.kerneltrap.org/taxonomy/term/1065">Christian Borntraeger</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/478">high memory</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/583">patch</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/477">RAM</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/1064">ramdisk</category>
 <category domain="http://www.kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Thu, 11 Oct 2007 20:01:06 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">14565 at http://www.kerneltrap.org</guid>
</item>
<item>
 <title>Improving kswapd</title>
 <link>http://www.kerneltrap.org/node/14294</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;The current VM can get itself into trouble fairly easily on systems with a small ZONE_HIGHMEM, which is common on i686 computers with 1GB of memory,&lt;/i&gt;&quot; Rik van Riel said explaining a small patch to &lt;code&gt;cmscan.c&lt;/code&gt;.  He continued, &quot;&lt;i&gt;on one side, page_alloc() will allocate down to zone-&amp;gt;pages_low, while on the other side, kswapd() and balance_pgdat() will try to free memory from every zone, until every zone has more free pages than zone-&amp;gt;pages_high.&lt;/i&gt;&quot;  He noted that highmem could be filled up with &quot;&lt;i&gt;page tables, ramfs, vmalloc allocations and other unswappable things quite easily and without many bad side effects, since we still have a huge ZONE_NORMAL to do future allocations from.  However, as long as the number of free pages in the highmem zone is below zone-&amp;gt;pages_high, kswapd will continue swapping things out from ZONE_NORMAL, too!  Sami Farin managed to get his system into a stage where kswapd had freed about 700MB of low memory and was still &#039;going strong&#039;.&lt;/i&gt;&quot;  He described his patch:&lt;/p&gt;
&lt;blockquote&