Bug 30462 - High cpu usage when someone sends many ipv6 udp packages
Summary: High cpu usage when someone sends many ipv6 udp packages
Status: CLOSED CODE_FIX
Alias: None
Product: Networking
Classification: Unclassified
Component: IPV6 (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Hideaki YOSHIFUJI
URL:
Keywords:
Depends on:
Blocks: 27352
  Show dependency tree
 
Reported: 2011-03-05 01:10 UTC by Ernst Sjöstrand
Modified: 2011-03-14 17:24 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.38-rc3
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Ernst Sjöstrand 2011-03-05 01:10:49 UTC
Hi,

while testing ipv6 performance on my local network I found the following problem.
When sending lots of UDP packages over ipv6 to a machine running kernel 2.6.38-rc3 or later that machines become heavily loaded and X may stop responding for long periods of time for example, sound skips etc.
A ksoftirqd and kworker thread each run 100% on my machine.

I'm using this command to trigger this:
iperf -c fe80::21f:d0ff:fe54:1ad4%eth0 -b 1000M -u -V
You _don't_ have to setup an iperf server on the reciever.

I have a gigabit network with a WNDR3700 with the new V1.0.7.98 firmware that's "IPv6 ready".

I've used the kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ to narrow down that this happens with 2.6.38-rc3 and later but not with 2.6.38-rc2 and earlier like 2.6.37 and 2.6.35.

The following ipv6 related changes were introduced between -rc2 and -rc3 that I can see. The "Revert 'administrative down' address handling changes." looked big...
      ipv6: Always clone offlink routes.
      ipv6: Revert 'administrative down' address handling changes.
Comment 1 Andrew Morton 2011-03-05 01:16:20 UTC
(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Sat, 5 Mar 2011 01:10:53 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=30462
> 
>            Summary: High cpu usage when someone sends many ipv6 udp
>                     packages
>            Product: Networking
>            Version: 2.5
>     Kernel Version: 2.6.38-rc3
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: high
>           Priority: P1
>          Component: IPV6
>         AssignedTo: yoshfuji@linux-ipv6.org
>         ReportedBy: ernstp@gmail.com
>         Regression: Yes
> 
> 
> Hi,
> 
> while testing ipv6 performance on my local network I found the following
> problem.
> When sending lots of UDP packages over ipv6 to a machine running kernel
> 2.6.38-rc3 or later that machines become heavily loaded and X may stop
> responding for long periods of time for example, sound skips etc.
> A ksoftirqd and kworker thread each run 100% on my machine.
> 
> I'm using this command to trigger this:
> iperf -c fe80::21f:d0ff:fe54:1ad4%eth0 -b 1000M -u -V
> You _don't_ have to setup an iperf server on the reciever.
> 
> I have a gigabit network with a WNDR3700 with the new V1.0.7.98 firmware
> that's
> "IPv6 ready".
> 
> I've used the kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ to
> narrow down that this happens with 2.6.38-rc3 and later but not with
> 2.6.38-rc2
> and earlier like 2.6.37 and 2.6.35.
> 
> The following ipv6 related changes were introduced between -rc2 and -rc3 that
> I
> can see. The "Revert 'administrative down' address handling changes." looked
> big...
>       ipv6: Always clone offlink routes.
>       ipv6: Revert 'administrative down' address handling changes.
>
Comment 2 David S. Miller 2011-03-05 01:21:43 UTC
From: Andrew Morton <akpm@linux-foundation.org>
Date: Fri, 4 Mar 2011 17:15:06 -0800

>> The following ipv6 related changes were introduced between -rc2 and -rc3
>> that I
>> can see. The "Revert 'administrative down' address handling changes." looked
>> big...
>>       ipv6: Always clone offlink routes.
>>       ipv6: Revert 'administrative down' address handling changes.

Can we narrow it down to which of those two changes introduced the
regression?

We have another issue, still open, which is caused by the first
change, so maybe try reverting that one first.

Thanks.
Comment 3 Ernst Sjöstrand 2011-03-05 01:27:04 UTC
I've only used precompiled kernels so far so I don't have stuff set up to
compile kernels right now,
probably won't have time to do that this weekend. Not tonight in GMT+1
anyway!

Regards
//Ernst

On Sat, Mar 5, 2011 at 02:21, David Miller <davem@davemloft.net> wrote:

> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Fri, 4 Mar 2011 17:15:06 -0800
>
> >> The following ipv6 related changes were introduced between -rc2 and -rc3
> that I
> >> can see. The "Revert 'administrative down' address handling changes."
> looked
> >> big...
> >>       ipv6: Always clone offlink routes.
> >>       ipv6: Revert 'administrative down' address handling changes.
>
> Can we narrow it down to which of those two changes introduced the
> regression?
>
> We have another issue, still open, which is caused by the first
> change, so maybe try reverting that one first.
>
> Thanks.
>
Comment 4 Ernst Sjöstrand 2011-03-07 19:54:43 UTC
Hi,

seems like reverting "ipv6: Always clone offlink routes." fixes the issue.

Regards
//Ernst

2011/3/5 Ernst Sjöstrand <ernstp@gmail.com>:
> I've only used precompiled kernels so far so I don't have stuff set up to
> compile kernels right now,
> probably won't have time to do that this weekend. Not tonight in GMT+1
> anyway!
>
> Regards
> //Ernst
>
> On Sat, Mar 5, 2011 at 02:21, David Miller <davem@davemloft.net> wrote:
>>
>> From: Andrew Morton <akpm@linux-foundation.org>
>> Date: Fri, 4 Mar 2011 17:15:06 -0800
>>
>> >> The following ipv6 related changes were introduced between -rc2 and
>> >> -rc3 that I
>> >> can see. The "Revert 'administrative down' address handling changes."
>> >> looked
>> >> big...
>> >>       ipv6: Always clone offlink routes.
>> >>       ipv6: Revert 'administrative down' address handling changes.
>>
>> Can we narrow it down to which of those two changes introduced the
>> regression?
>>
>> We have another issue, still open, which is caused by the first
>> change, so maybe try reverting that one first.
>>
>> Thanks.
>
>
Comment 5 Florian Mickler 2011-03-14 17:23:24 UTC
There was a commit merged for 2.6.38-rc9 (or final) which mentions this bug report:

commit 7343ff31ebf01691ea4515d3126467434b9d22d6
Author: David S. Miller <davem@davemloft.net>
Date:   Wed Mar 9 19:55:25 2011 -0800

    ipv6: Don't create clones of host routes.

Note You need to log in before you can comment on or make changes to this bug.