<?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 - sg chaining</title>
 <link>http://kerneltrap.org/taxonomy/term/982/0</link>
 <description></description>
 <language>en-local</language>
<item>
 <title>2.6.24-rc1, &quot;One of the Biggest -rc Releases Ever&quot;</title>
 <link>http://kerneltrap.org/Linux/2.6.24-rc1_One_of_the_Biggest_-rc_Releases_Ever</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;This may count as one of the biggest -rc releases ever. It&#039;s humongous. Usually the compressed -rc1 diffs are in the 3-5MB range, with occasional smaller ones, and the occasional ones that top 6M, but this one is *eleven* megs,&lt;/i&gt;&quot; &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2007/10/24/352404&quot;&gt;Linus Torvalds announced&lt;/a&gt; the first release candidate of the upcoming 2.6.24 kernel.  He summarized some of the changes, &quot;&lt;i&gt;in short, we just had an unusually large amount of not just x86 merges, but also tons of new drivers (wireless networking stands out, but is by no  means the only thing - we&#039;ve got dvb, regular wired network, mmc etc all joining in), and a fair amount or architecture stuff, filesystems, networking etc too.&lt;/i&gt;&quot;  He added:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;In other words, I don&#039;t even know where to start. The big noticeable thing is the x86 merge, and I think we all fervently hope that it won&#039;t cause any issues. So far it&#039;s been pretty smooth sailing. Knock wood.  Less smooth has the scatter-gather changes to the block layer been, but they are hopefully all in reasonable shape by now too. And the VM changes? I honestly hope nobody even notices. Same goes for some of the VFS layer changes that affected basically every filesystem (although in mostly very straightforward ways).&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://kerneltrap.org/Linux/2.6.24-rc1_One_of_the_Biggest_-rc_Releases_Ever&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://kerneltrap.org/Linux/2.6.24-rc1_One_of_the_Biggest_-rc_Releases_Ever#comments</comments>
 <category domain="http://kerneltrap.org/-rc">-rc</category>
 <category domain="http://kerneltrap.org/-rc1">-rc1</category>
 <category domain="http://kerneltrap.org/2.6.24">2.6.24</category>
 <category domain="http://kerneltrap.org/Linus_Torvalds">Linus Torvalds</category>
 <category domain="http://kerneltrap.org/Linux">Linux</category>
 <category domain="http://kerneltrap.org/sg_chaining">sg chaining</category>
 <category domain="http://kerneltrap.org/x86_unification">x86 unification</category>
 <category domain="http://kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Wed, 24 Oct 2007 14:27:55 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">14663 at http://kerneltrap.org</guid>
</item>
<item>
 <title>SG Chaining Merged</title>
 <link>http://kerneltrap.org/Linux/SG_Chaining_Merged</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;I think the SG stuff looks ok now, but I think we have a lot of &#039;fix up the rough edges&#039; to go!&lt;/i&gt;&quot; &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2007/10/23/351488&quot;&gt;Linus Torvalds noted&lt;/a&gt; regarding some of the fallout from the recent merge of Jens Axboe&#039;s &lt;a href=&quot;http://kerneltrap.org/sg_chaining&quot;&gt;SG chaining&lt;/a&gt; patchset.  During one of the many discussions, Jens explained:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;It&#039;s all about the end goal - having maintainable and resilient code.  And I think the sg code will be better once we get past the next day or so, and it&#039;ll be more robust. That is what matters to me, not the simplicity of the patch itself.&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Boaz Harrosh commented, &quot;&lt;i&gt;thanks Jens for doing all this, The performance gain is substantial and we will all enjoy it.&lt;/i&gt;&quot;  Jens replied, &quot;&lt;i&gt;my pleasure, I just wish it could have been a little less painful. But in a day or two, it should all be behind us and we can move forward with making good use of it.&lt;/i&gt;&quot;&lt;/p&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://kerneltrap.org/Linux/SG_Chaining_Merged&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://kerneltrap.org/Linux/SG_Chaining_Merged#comments</comments>
 <category domain="http://kerneltrap.org/taxonomy/term/1106">Boaz Harrosh</category>
 <category domain="http://kerneltrap.org/Jens_Axboe">Jens Axboe</category>
 <category domain="http://kerneltrap.org/Linus_Torvalds">Linus Torvalds</category>
 <category domain="http://kerneltrap.org/Linux">Linux</category>
 <category domain="http://kerneltrap.org/merge_window">merge window</category>
 <category domain="http://kerneltrap.org/sg_chaining">sg chaining</category>
 <category domain="http://kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Tue, 23 Oct 2007 19:56:24 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">14658 at http://kerneltrap.org</guid>
</item>
<item>
 <title>SG Chaining Performance</title>
 <link>http://kerneltrap.org/Linux/SG_Chaining_Performance</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;Jens Axboe &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2007/9/21/265259&quot;&gt;detailed the changes&lt;/a&gt; in his &lt;a href=&quot;http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=summary&quot;&gt;linux-2.6-block.git&lt;/a&gt; tree that he plans to merge into the upcoming 2.6.24 kernel.  Among the changes were the necessary updates to enable SG chaining which is used for &lt;a href=&quot;http://kerneltrap.org/node/8176&quot;&gt;large IO commands&lt;/a&gt;, &quot;&lt;i&gt;the goal of sg chaining is to allow support for very large sgtables, without requiring that they be allocated from one contigious piece of memory.&lt;/i&gt;&quot;  Andrew Morton asked for more information, &quot;&lt;i&gt;presumably sg chaining means more overhead on the IO submission paths?  If so, has this been quantified?&lt;/i&gt;&quot;&lt;/p&gt;
&lt;p&gt;Jens explained that there is no overhead for existing logic which doesn&#039;t use sg chaining, &quot;&lt;i&gt;just cleanups to drivers to use &lt;code&gt;sg_next()&lt;/code&gt; and &lt;code&gt;for_each_sg()&lt;/code&gt; and so on.&lt;/i&gt;&quot;  He continued:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;For actually using the sg chaining, there&#039;s some overhead of course. Say we support 256 entries without chaining, or 1mb with 4kb pages. A request with 1000 entried would require 4 trips to the allocator to allocate the chainable lists and 4 trips when freeing that list again.  We don&#039;t loop the sg list on setup of freeing, just jump to the correct locations.  So even for chaining, the cost isn&#039;t that big. It enables us to support much larger I