From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: dipankar@in.ibm.com, Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
Andi Kleen <ak@suse.de>
Subject: Re: [PATCH/RFC] synchronize_rcu(): high latency on idle system
Date: Sat, 12 Jan 2008 10:23:11 +0100 [thread overview]
Message-ID: <1200129791.7999.5.camel@lappy> (raw)
In-Reply-To: <20080112012626.GI28570@kvack.org>
On Fri, 2008-01-11 at 20:26 -0500, Benjamin LaHaise wrote:
> Hello folks,
>
> I'd like to put the patch below out for comments to see if folks think the
> approach is a valid fix to reduce the latency of synchronize_rcu(). The
> motivation is that an otherwise idle system takes about 3 ticks per network
> interface in unregister_netdev() due to multiple calls to synchronize_rcu(),
> which adds up to quite a few seconds for tearing down thousands of
> interfaces. By flushing pending rcu callbacks in the idle loop, the system
> makes progress hundreds of times faster. If this is indeed a sane thing to,
> it probably needs to be done for other architectures than x86. And yes, the
> network stack shouldn't call synchronize_rcu() quite so much, but fixing that
> is a little more involved.
So, instead of only relying on the tick to drive the RCU state machine,
you add the idle loop to it. This seems to make sense, esp because nohz
is held off until rcu is idle too.
Even though Andi is right in that its not the proper solution to your
problem, I think its worth doing anyway for the general benefit of RCU.
But lets ask Paul, he is Mr RCU after all :-)
> diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
> index 9663c2a..592f6e4 100644
> --- a/arch/x86/kernel/process_32.c
> +++ b/arch/x86/kernel/process_32.c
> @@ -188,6 +188,9 @@ void cpu_idle(void)
> rmb();
> idle = pm_idle;
>
> + if (rcu_pending(cpu))
> + rcu_check_callbacks(cpu, 0);
> +
> if (!idle)
> idle = default_idle;
>
next prev parent reply other threads:[~2008-01-12 9:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-12 1:26 [PATCH/RFC] synchronize_rcu(): high latency on idle system Benjamin LaHaise
2008-01-12 2:37 ` Andi Kleen
2008-01-12 17:51 ` Benjamin LaHaise
2008-01-12 18:35 ` Andi Kleen
2008-01-12 9:23 ` Peter Zijlstra [this message]
2008-01-12 16:55 ` Paul E. McKenney
2008-01-12 17:33 ` Andi Kleen
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=1200129791.7999.5.camel@lappy \
--to=a.p.zijlstra@chello.nl \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=bcrl@kvack.org \
--cc=dipankar@in.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).