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