From: Eric Dumazet <dada1@cosmosbay•com>
To: Benjamin LaHaise <bcrl@lhnet•ca>,
"Paul E. McKenney" <paulmck@linux•vnet.ibm.com>
Cc: Denys Fedoryschenko <denys@visp•net.lb>,
netdev@vger•kernel.org,
linux kernel <linux-kernel@vger•kernel.org>,
damien.wyart@free•fr
Subject: Re: regression: unregister_netdev() unusably slow
Date: Mon, 25 May 2009 07:22:02 +0200 [thread overview]
Message-ID: <4A1A2AFA.8020605@cosmosbay.com> (raw)
In-Reply-To: <20090525000050.GJ24757@kvack.org>
Benjamin LaHaise a écrit :
> On Mon, May 25, 2009 at 12:47:39AM +0200, Eric Dumazet wrote:
>> There is a strong dependancy against HZ
>> BTW, I am using TREE_RCU
>
> I'm using CLASSIC_RCU. The bisect just completed, and it points to RCU.
> It makes some degree of sense since I'm testing on an otherwise idle
> machine. That said, where is fixing it going to make sense? I'm not
> opposed to having device unregister take a few timer ticks, but there
> has to be some way of exposing parallelism to the system, and since the
> synchronize_net() calls are done under rntl_lock(), none is possible at
> present. Hrm.
Thanks Ben, this bisection indeed confirms how nasty synchronize_rcu() is :)
Time to include Paul and lkml in the discussion, and find a better solution than
one provided in February.
>
> -ben
>
> bf51935f3e988e0ed6f34b55593e5912f990750a is first bad commit
> commit bf51935f3e988e0ed6f34b55593e5912f990750a
> Author: Paul E. McKenney <paulmck@linux•vnet.ibm.com>
> Date: Tue Feb 17 06:01:30 2009 -0800
>
> x86, rcu: fix strange load average and ksoftirqd behavior
>
> Damien Wyart reported high ksoftirqd CPU usage (20%) on an
> otherwise idle system.
>
> The function-graph trace Damien provided:
> ...
> diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
>
> index a546f55..bd4da2a 100644
> --- a/arch/x86/kernel/process_32.c
> +++ b/arch/x86/kernel/process_32.c
> @@ -104,9 +104,6 @@ void cpu_idle(void)
> check_pgt_cache();
> rmb();
>
> - if (rcu_pending(cpu))
> - rcu_check_callbacks(cpu, 0);
> -
> if (cpu_is_offline(cpu))
> play_dead();
>
>
> --
Paul, this commit makes net device unregister very slow (more than 100 ms
if CONFIG_NO_HZ is set), while it used to be pretty fast in previous kernels.
Quoting Ben :
" I just ran a few L2TP tests against 2.6.30-rc7, and it looks like network
device deletion has become unusably slow. At least in 2.6.27.10, deleting
1000 network interfaces takes less than 2 seconds of real time. The same
test run under 2.6.30-rc7 is taking hundreds of seconds to delete 1000
interfaces at a rate of about 5 per second. The interfaces all share the
same local ip address, but each have a single route to a unique client
ip address."
Device unregister is a synchronize_rcu() abuser (three calls to dismantle
a vlan...) so delaying rcu callbacks can be pretty expensive for it.
I wonder if the real root of the problem was not discovered in the meantime,
by commit 64ca5ab913f1594ef316556e65f5eae63ff50cee
rcu: increment quiescent state counter in ksoftirqd()
Maybe this commit solved Damien Wyart problem as well, and we can revert
commit bf51935f3e988e0ed6f34b55593e5912f990750a ?
Thank you
next prev parent reply other threads:[~2009-05-25 5:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-24 19:21 regression: unregister_netdev() unusably slow Benjamin LaHaise
2009-05-24 21:23 ` Denys Fedoryschenko
2009-05-24 21:37 ` Benjamin LaHaise
2009-05-24 21:42 ` Eric Dumazet
2009-05-24 21:44 ` Benjamin LaHaise
2009-05-24 22:07 ` Eric Dumazet
2009-05-24 22:12 ` Benjamin LaHaise
2009-05-24 22:47 ` Eric Dumazet
2009-05-25 0:00 ` Benjamin LaHaise
2009-05-25 5:22 ` Eric Dumazet [this message]
2009-05-25 8:04 ` Damien Wyart
2009-05-25 16:21 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A1A2AFA.8020605@cosmosbay.com \
--to=dada1@cosmosbay$(echo .)com \
--cc=bcrl@lhnet$(echo .)ca \
--cc=damien.wyart@free$(echo .)fr \
--cc=denys@visp$(echo .)net.lb \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=paulmck@linux$(echo .)vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox