From: Frederic Weisbecker <fweisbec@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Richard Henderson <rth@twiddle.net>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
alpha <linux-alpha@vger.kernel.org>,
"3.2.x.." <stable@kernel.org>
Subject: Re: [PATCH 01/10] alpha: Add missing RCU idle APIs on idle loop
Date: Thu, 23 Aug 2012 12:42:11 +0200 [thread overview]
Message-ID: <20120823104201.GA18251@somewhere.redhat.com> (raw)
In-Reply-To: <20120822190109.GH2447@linux.vnet.ibm.com>
On Wed, Aug 22, 2012 at 12:01:09PM -0700, Paul E. McKenney wrote:
> > The current code is preemptable, at least it appears so because it calls
> > schedule() directly. And if I call rcu_idle_enter() in a preemptable section,
> > I'm in trouble because I'll schedule while in extended QS.
> >
> > Thus I need to disable preemption here at least until I call rcu_idle_exit().
> >
> > Now this is an endless loop so there is no need to re-enable
> > preemption after the loop. And schedule_preempt_disabled()
> > takes care of enabling preemption before schedule() and redisabling
> > it afterward.
> >
> >
> > >
> > > Thanx, Paul
> > >
> > > > while (1) {
> > > > /* FIXME -- EV6 and LCA45 know how to power down
> > > > the CPU. */
> > > >
> > > > + rcu_idle_enter();
> > > > while (!need_resched())
> > > > cpu_relax();
> > > > - schedule();
> > > > + rcu_idle_exit();
> > > > + schedule_preempt_disabled();
> > > > }
>
> Understood, but what I don't understand is why you don't need a
> preempt_enable() right here.
Look, let's inline the content of schedule_preempt_disabled(), the code
then looks like:
void cpu_idle(void)
{
set_thread_flag(TIF_POLLING_NRFLAG);
preempt_disable();
while (1) {
/* FIXME -- EV6 and LCA45 know how to power down
the CPU. */
rcu_idle_enter();
while (!need_resched())
cpu_relax();
rcu_idle_exit();
sched_preempt_enable_no_resched();
schedule();
preempt_disable();
}
}
So there is a preempt_enable() before we schedule, then we re-disable
preemption after schedule.
Now I realize cpu_idle() is supposed to be called with preemption disabled
already so I shouldn't add an explicit preempt_disable() or it's going to be worse.
But that means there is an existing bug here in alpha, it should call schedule_preempt_disabled()
instead of schedule(). cpu_idle() is called with preemption disabled on the boot CPU.
And it should as well from the secondary CPUs entry but alpha doesn't seem to do that.
So I need to fix that first. I'll respin.
next prev parent reply other threads:[~2012-08-23 10:42 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-22 16:23 [PATCH 00/10] rcu: Add missing RCU idle APIs on idle loop Frederic Weisbecker
2012-08-22 16:23 ` Frederic Weisbecker
2012-08-22 16:23 ` [PATCH 01/10] alpha: " Frederic Weisbecker
2012-08-22 17:19 ` Paul E. McKenney
2012-08-22 17:35 ` Frederic Weisbecker
2012-08-22 19:01 ` Paul E. McKenney
2012-08-23 10:42 ` Frederic Weisbecker [this message]
2012-08-23 12:25 ` Paul E. McKenney
2012-08-23 9:32 ` Michael Cree
2012-08-23 10:58 ` Frederic Weisbecker
2012-08-22 16:23 ` [PATCH 02/10] cris: " Frederic Weisbecker
2012-08-22 16:23 ` [PATCH 03/10] frv: " Frederic Weisbecker
2012-08-22 16:23 ` [PATCH 04/10] h8300: " Frederic Weisbecker
2012-08-22 16:23 ` [PATCH 05/10] m32r: " Frederic Weisbecker
2012-08-22 16:23 ` [PATCH 06/10] m68k: " Frederic Weisbecker
2012-08-22 16:23 ` Frederic Weisbecker
2012-08-22 16:23 ` [PATCH 07/10] mn10300: " Frederic Weisbecker
2012-08-22 16:23 ` [PATCH 08/10] parisc: " Frederic Weisbecker
2012-08-24 13:26 ` John David Anglin
2012-08-22 16:23 ` [PATCH 09/10] score: " Frederic Weisbecker
2012-08-22 16:23 ` [PATCH 10/10] xtensa: " Frederic Weisbecker
2012-08-22 17:18 ` [PATCH 00/10] rcu: " Geert Uytterhoeven
2012-08-22 17:18 ` Geert Uytterhoeven
2012-08-22 17:18 ` Geert Uytterhoeven
2012-08-23 11:02 ` Frederic Weisbecker
2012-08-23 11:02 ` Frederic Weisbecker
2012-08-23 20:23 ` Geert Uytterhoeven
2012-08-23 20:23 ` Geert Uytterhoeven
2012-08-23 21:50 ` Frederic Weisbecker
2012-08-23 21:50 ` Frederic Weisbecker
2012-08-23 21:50 ` Frederic Weisbecker
2012-09-17 20:31 ` Geert Uytterhoeven
2012-09-17 20:31 ` Geert Uytterhoeven
2012-09-17 20:31 ` Geert Uytterhoeven
2012-09-17 20:55 ` Paul E. McKenney
2012-09-17 20:55 ` Paul E. McKenney
2012-08-23 20:23 ` Geert Uytterhoeven
2012-08-23 11:02 ` Frederic Weisbecker
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=20120823104201.GA18251@somewhere.redhat.com \
--to=fweisbec@gmail.com \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mattst88@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rth@twiddle.net \
--cc=stable@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.