<?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 - 4k stacks</title>
 <link>http://www.kerneltrap.org/taxonomy/term/621/0</link>
 <description></description>
 <language>en-local</language>
<item>
 <title>Defaulting To 4K Stacks</title>
 <link>http://www.kerneltrap.org/Linux/Defaulting_To_4K_Stacks</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;Andrew Morton &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2008/4/18/1498474&quot;&gt;replied to a commit message&lt;/a&gt; making 4k stacks the default, saying, &quot;&lt;i&gt;this patch will cause kernels to crash.&lt;/i&gt;&quot;  Ingo Molnar replied, &quot;&lt;i&gt;what mainline kernels crash and how will they crash? Fedora and other distros have had 4K stacks enabled for years.&lt;/i&gt;&quot;  He added, &quot;&lt;i&gt;we&#039;ve conducted tens of thousands of bootup tests with all sorts of drivers and kernel options enabled and have yet to see a single crash due to 4K stacks.&lt;/i&gt;&quot;  During the lengthy discussion it was suggested that nfs+xfs+raid kernel configurations, and using ndiswrapper are the most common reasons for overflowing a 4K stack size.&lt;/p&gt;
&lt;p&gt;Andi Kleen questioned the usefulness of 4k stacks, &quot;&lt;i&gt;as far as I can figure out they are not [a worthy goal]. They might have been a worthy goal on crappy 2.4 VMs, but these times are long gone.&lt;/i&gt;&quot;  Arjan van de Ven suggested that though the 2.6 VM is much improved over the 2.4 VM, fragmentation with 8K stacks remains an unsolvable problem,  &quot;&lt;i&gt;it&#039;s basic math; the Linux VM gets to deal with both short and long lasting allocations; no matter how hard you try to get some degree of fragmentation; especially due to the 15:1 acceleration you get due to the lowmem issue.  And before you say &#039;you should use 64 bit on such machines&#039;; I would love it if more people used 64 bit linux. Sadly the adoption rate of that is not very good still.... by far ;(&lt;/i&gt;&quot;  In another email, Arjan listed two advantages to 4K stacks, &quot;&lt;i&gt;1) less memory consumption in the lowmem zone (critical for enterprise use, also good for general performance), and 2) kernel stacks at 8K are one of the most prominent order-1 allocations in the kernel; again with big-memory systems the fragmentation of the lowmem zone is a problem (and the distros that ship 4K stacks went there because of customer complaints)&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/Defaulting_To_4K_Stacks&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.kerneltrap.org/Linux/Defaulting_To_4K_Stacks#comments</comments>
 <category domain="http://www.kerneltrap.org/4k_stacks">4k stacks</category>
 <category domain="http://www.kerneltrap.org/8k_stacks">8k stacks</category>
 <category domain="http://www.kerneltrap.org/Andi_Kleen">Andi Kleen</category>
 <category domain="http://www.kerneltrap.org/Andrew_Morton">Andrew Morton</category>
 <category domain="http://www.kerneltrap.org/Arjan_van_de_Ven">Arjan van de Ven</category>
 <category domain="http://www.kerneltrap.org/Ingo_Molnar">Ingo Molnar</category>
 <category domain="http://www.kerneltrap.org/Linux">Linux</category>
 <category domain="http://www.kerneltrap.org/merge_window">merge window</category>
 <category domain="http://www.kerneltrap.org/NDISwrapper">NDISwrapper</category>
 <category domain="http://www.kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Wed, 23 Apr 2008 01:42:24 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">16036 at http://www.kerneltrap.org</guid>
</item>
<item>
 <title>Linux: Moving 4K Stacks Forward</title>
 <link>http://www.kerneltrap.org/Linux/Moving_4K_Stacks_Forward</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;In a series of 5 patches, Jesper Juhl propsed moving 4K stacks from a debug feature to a non-debug feature, defaulting it to be enabled in the -mm tree.  He referred back to a lengthy &lt;a href=&quot;http://lkml.org/lkml/2007/7/11/294&quot;&gt;earlier discussion&lt;/a&gt; in which he had proposed making 4K stacks the default in the mainline kernel, then added:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;Based on the comments in that thread I conclude that 4KSTACKS are not really  considered a debug-only feature any longer, but the time is not right (yet) to make them the default - and it&#039;s certainly not yet the time to get rid of 8K stacks.&quot;&lt;/p&gt;
&lt;p&gt;&quot;In that thread I promised to provide some patches that would lift 4KSTACKS out of debug-only feature status, which is what the first two patches in this series do.  I also said I would provide a patch to make 4KSTACKS &#039;default y&#039; to get more testing, but restrict that patch to -mm - that&#039;s the fifth patch in this series.  Patches 3 &amp;amp; 4 in this series move the config option out of the Kernel hacking menu and into Processor types and features&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/Moving_4K_Stacks_Forward&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.kerneltrap.org/Linux/Moving_4K_Stacks_Forward#comments</comments>
 <category domain="http://www.kerneltrap.org/-mm">-mm</category>
 <category domain="http://www.kerneltrap.org/4k_stacks">4k stacks</category>
 <category domain="http://www.kerneltrap.org/8k_stacks">8k stacks</category>
 <category domain="http://www.kerneltrap.org/debug">debug</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/242">Jesper Juhl</category>
 <category domain="http://www.kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Thu, 16 Aug 2007 20:42:16 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">14194 at http://www.kerneltrap.org</guid>
</item>
<item>
 <title>Linux:  Batched Writes</title>
 <link>http://www.kerneltrap.org/node/6739</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;Hans Reiser [&lt;a href=&quot;http://kerneltrap.org/node/5654&quot;&gt;interview&lt;/a&gt;] described a recently posted patch as, &quot;&lt;i&gt;it revises the existing reiser4 code to do a good job for writes that are larger than 4k at a time by assiduously adhering to the principle that things that need to be done once per write should be done once per write, not once per 4k.&lt;/i&gt;&quot;  He went on to explain, &quot;&lt;i&gt;this code empirically proves that the generic code design which passes 4k at a time to the underlying FS can be improved.  Performance results show that the new code consumes  40% less CPU when doing &#039;dd bs=1MB .....&#039;&lt;/i&gt;&quot;  Referring to &lt;code&gt;generic_file_write()&lt;/code&gt;, he further noted that currently when writing 64MB of data, &quot;&lt;i&gt;it may go to the kernel as a 64MB write, but VFS sends it to the FS as 64MB/4k separate 4k writes.&lt;/i&gt;