<P>&nbsp;<BR><BR><FONT SIZE=2><B>ebiederm@xmission.com (Eric W. Biederman)</B></FONT><BR><FONT SIZE=2>22/03/2007 14:02 CST</FONT><BR><BR> <FONT SIZE=2>Pour :</FONT> <FONT SIZE=2>Benjamin Thery &lt;benjamin.thery@bull.net&gt;</FONT><BR> <FONT SIZE=2>cc :</FONT> <FONT SIZE=2>&quot;Denis V. Lunev&quot; &lt;den@sw.ru&gt;, Linux Containers &lt;containers@lists.osdl.org&gt;, Dave Hansen &lt;hansendc@us.ibm.com&gt;</FONT><BR> <FONT SIZE=2>ccc :</FONT> <BR> <FONT SIZE=2>Objet :</FONT> <FONT SIZE=2>Re: [Devel] Re: [PATCHSET] 2.6.20-lxc8</FONT><BR> <BR></P><P><FONT FACE="Courier New">Benjamin Thery &lt;benjamin.thery@bull.net&gt; writes:<BR></FONT><BR><FONT FACE="Courier New">&gt;&gt; My investigations on the increase of cpu load when running netperf inside a<BR>&gt;&gt; container (ie. through etun2&lt;-&gt;etun1) is progressing slowly.<BR>&gt;&gt;<BR>&gt;&gt; I'm not sure the cause is fragmentation as we supposed initially.<BR>&gt;&gt; In fact, it seems related to forwarding the packets between the devices.<BR>&gt;&gt;<BR>&gt;&gt; Here is what I've tracked so far:<BR>&gt;&gt; * when we run netperf from the container, oprofile reports that the top<BR>&gt;&gt; &quot;consuming&quot; symbol is: &quot;pskb_expand_head&quot;. Next comes<BR>&gt;&gt; 9.7% of the samples.<BR>&gt;&gt; * Without container, these symbols don't show up in the first 20 entries.<BR>&gt;&gt;<BR>&gt;&gt; Who is calling &quot;pskb_expand_head&quot; in this case?<BR>&gt;&gt;<BR>&gt;&gt; Using systemtap, I determined that the call to &quot;pskb_expand_head&quot; comes from the<BR>&gt;&gt; skb_cow() in ip_forward() (l.90 in 2.6.20-rc5-netns).<BR>&gt;&gt;<BR>&gt;&gt; The number of calls to &quot;pskb_expand_head&quot; matches the number of invocations of<BR>&gt;&gt; ip_forward() (268000 calls for a 20 seconds netperf session in my case).<BR></FONT>&gt;<BR><FONT FACE="Courier New">&gt; Ok. This seems to make sense, and is related to how we have configured the<BR>&gt; network in this case.</FONT></P><P>&gt;<BR><FONT FACE="Courier New">&gt; It looks like pskb_expand_head is called by skb_cow.<BR></FONT>&gt;<BR><FONT FACE="Courier New">&gt; skb_cow has two cases when it calls pskb_expand_head.<BR>&gt; - When there are multiple people who have a copy of the packet</FONT><BR><FONT FACE="Courier New">&gt; (tcpdump and friends)<BR>&gt; - When there isn't enough room for the hard header.<BR></FONT>&gt;<BR><FONT FACE="Courier New">&gt; Any chance one of you guys looking into this can instrument up<BR>&gt; ip_foward just before the call to skb_cow and find out which<BR>&gt; reason it is?<BR></FONT></P><P><FONT FACE="Courier New">Not right now. I'm off until Monday.</FONT></P><P><FONT FACE="Courier New">But I'll be happy to do this on Monday morning.</FONT></P><P><BR><FONT FACE="Courier New">&gt; A cheap trick to make the overhead go away is probably to setup<BR>&gt; ethernet bridging in this case...<BR></FONT><BR><FONT FACE="Courier New">&gt; But if we can ensure the ip_foward case does not need to do anything<BR>&gt; more than modify the ttl and update the destination that would<BR>&gt; be good to.<BR></FONT><BR><FONT FACE="Courier New">&gt; Anyway this does look very solvable.</FONT></P><P>&nbsp;</P><P><FONT FACE="Courier New">Good news.<BR>Thanks for the input.</FONT></P><P>&nbsp;</P><P>Benjamin</P><P><BR><FONT FACE="Courier New">&gt; Eric<BR></FONT></P>