From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Christoph Lameter <cl@linux.com>,
Alok Kataria <akataria@vmware.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
the arch/x86 maintainers <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] x86: Reduce the default HZ value
Date: Fri, 8 May 2009 05:50:23 -0700 [thread overview]
Message-ID: <20090508125023.GA6935@linux.vnet.ibm.com> (raw)
In-Reply-To: <1241778776.6311.2585.camel@laptop>
On Fri, May 08, 2009 at 12:32:56PM +0200, Peter Zijlstra wrote:
> On Thu, 2009-05-07 at 11:01 -0700, Paul E. McKenney wrote:
>
> > In general, I agree. However, in the case where you have a single
> > CPU-bound task running in user mode, you don't care that much about
> > syscall performance. So, yes, this would mean having yet another config
> > variable that users running big CPU-bound scientific applications would
> > need to worry about, which is not perfect either.
> >
> > For whatever it is worth, the added overhead on entry would be something
> > like the following:
> >
> > void rcu_irq_enter(void)
> > {
> > struct rcu_dynticks *rdtp = &__get_cpu_var(rcu_dynticks);
> >
> > if (rdtp->dynticks_nesting++)
> > return;
> > rdtp->dynticks++;
> > WARN_ON_RATELIMIT(!(rdtp->dynticks & 0x1), &rcu_rs);
> > smp_mb(); /* CPUs seeing ++ must see later RCU read-side crit sects */
> > }
> >
> > On exit, a bit more:
> >
> > void rcu_irq_exit(void)
> > {
> > struct rcu_dynticks *rdtp = &__get_cpu_var(rcu_dynticks);
> >
> > if (--rdtp->dynticks_nesting)
> > return;
> > smp_mb(); /* CPUs seeing ++ must see prior RCU read-side crit sects */
> > rdtp->dynticks++;
> > WARN_ON_RATELIMIT(rdtp->dynticks & 0x1, &rcu_rs);
> >
> > /* If the interrupt queued a callback, get out of dyntick mode. */
> > if (__get_cpu_var(rcu_data).nxtlist ||
> > __get_cpu_var(rcu_bh_data).nxtlist)
> > set_need_resched();
> > }
> >
> > But I could move the callback check into call_rcu(), which would get the
> > overhead of rcu_irq_exit() down to about that of rcu_irq_enter().
>
> Can't you simply enter idle state after a grace period completes and
> finds no pending callbacks for the next period. And leave idle state at
> the next call_rcu()?
If there were no RCU callbacks -globally- across all CPUs, yes. But
the check at the end of rcu_irq_exit() is testing only on the current
CPU. Checking across all CPUs is expensive and racy.
So what happens instead is that there is rcu_needs_cpu(), which gates
entry into dynticks-idle mode. This function returns 1 if there are
callbacks on the current CPU. So, if no CPU has an RCU callback, then
all CPUs can enter dynticks-idle mode so that the entire system is
quiescent from an RCU viewpoint -- no RCU processing at all.
Or am I missing what you are getting at with your question?
Thanx, Paul
next prev parent reply other threads:[~2009-05-08 12:50 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-04 18:44 [PATCH] x86: Reduce the default HZ value Alok Kataria
2009-05-05 21:21 ` H. Peter Anvin
2009-05-05 21:44 ` Alan Cox
2009-05-05 22:09 ` Alok Kataria
2009-05-05 22:33 ` Alan Cox
2009-05-05 23:37 ` Alok Kataria
2009-05-07 14:09 ` Christoph Lameter
2009-05-07 15:12 ` Alan Cox
2009-05-05 21:57 ` Alok Kataria
2009-05-07 14:13 ` Christoph Lameter
2009-05-07 15:14 ` Alan Cox
2009-05-07 15:20 ` Christoph Lameter
2009-05-07 15:30 ` H. Peter Anvin
2009-05-07 15:40 ` Christoph Lameter
2009-05-07 16:55 ` Jeff Garzik
2009-05-07 17:09 ` Alan Cox
2009-05-07 17:55 ` Jeff Garzik
2009-05-07 19:51 ` Alan Cox
2009-05-07 20:03 ` Jeff Garzik
2009-05-07 20:30 ` Alan Cox
2009-05-07 16:37 ` Alok Kataria
2009-05-07 17:07 ` Peter Zijlstra
2009-05-07 17:13 ` Peter Zijlstra
2009-05-07 17:18 ` Peter Zijlstra
2009-05-07 17:20 ` Christoph Lameter
2009-05-07 17:39 ` Peter Zijlstra
2009-05-07 17:40 ` Christoph Lameter
2009-05-07 17:54 ` Paul E. McKenney
2009-05-07 17:51 ` Christoph Lameter
2009-05-07 19:51 ` Paul E. McKenney
2009-05-07 17:36 ` Paul E. McKenney
2009-05-07 17:38 ` Peter Zijlstra
2009-05-07 18:01 ` Paul E. McKenney
2009-05-07 18:12 ` Christoph Lameter
2009-05-07 19:06 ` Paul E. McKenney
2009-05-07 19:53 ` Alan Cox
2009-05-07 19:56 ` Christoph Lameter
2009-05-07 20:24 ` Alan Cox
2009-05-07 20:21 ` Christoph Lameter
2009-05-08 10:32 ` Peter Zijlstra
2009-05-08 12:50 ` Paul E. McKenney [this message]
2009-05-08 14:16 ` Christoph Lameter
2009-05-08 15:06 ` Paul E. McKenney
2009-05-07 17:18 ` Christoph Lameter
2009-05-07 17:37 ` Peter Zijlstra
2009-05-07 17:34 ` Christoph Lameter
2009-05-07 17:55 ` Peter Zijlstra
2009-05-07 17:55 ` Christoph Lameter
2009-05-07 17:19 ` Christoph Lameter
2009-05-07 17:45 ` Peter Zijlstra
2009-05-07 17:50 ` Christoph Lameter
2009-05-07 19:17 ` Peter Zijlstra
2009-05-07 19:38 ` Christoph Lameter
2009-05-07 21:01 ` H. Peter Anvin
2009-05-07 16:35 ` Chris Snook
2009-05-07 16:56 ` Alok Kataria
2009-05-07 20:29 ` Chris Snook
2009-05-07 20:34 ` Alan Cox
2009-05-07 22:16 ` Ravikiran G Thirumalai
2009-05-07 22:19 ` Alok Kataria
2009-05-08 9:31 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2009-05-12 19:45 devzero
2009-05-13 23:30 ` Alok Kataria
2009-05-14 20:25 devzero
2009-05-14 20:29 ` Alan Cox
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=20090508125023.GA6935@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akataria@vmware.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cl@linux.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.