From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Josh Boyer <jwboyer@redhat.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@fedoraproject.org,
rostedt@goodmis.org
Subject: Re: Large slowdown with 'x86: Avoid invoking RCU when CPU is idle'
Date: Fri, 24 Feb 2012 08:51:30 -0800 [thread overview]
Message-ID: <20120224165130.GB2399@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120224162745.GC13903@zod.bos.redhat.com>
On Fri, Feb 24, 2012 at 11:27:46AM -0500, Josh Boyer wrote:
> On Fri, Feb 24, 2012 at 08:17:43AM -0800, Paul E. McKenney wrote:
> > On Fri, Feb 24, 2012 at 09:40:32AM -0500, Josh Boyer wrote:
> > > On Tue, Feb 21, 2012 at 08:42:43PM -0500, Josh Boyer wrote:
> > > > > And patch #47 in that series has been obsoleted by another series
> > > > > from Steven Rostedt:
> > > > >
> > > > > https://lkml.org/lkml/2012/2/7/231
> > > >
> > > > Ok.
> > > >
> > > > > Hopefully these fix both splats and slowness.
> > > >
> > > > So again, I'm slightly confused on how RCU patches flow. Eric
> > > > originally reported the bug for which you created the patch I applied
> > > > against 3.3. The giant patch series above seems queued for 3.4.
> > > >
> > > > I don't see stable CC'd on 45-47, nor any of Steven's patches. I doubt
> > > > I'd want to go applying the 47-patch series on 3.3 at the moment, and
> > > > given you have these marked for 3.4 I don't think you do either.
> > > > However, is there some kind of fix for the original bug report against
> > > > 3.3?
> > >
> > > I was being sincere when I asked the above questions. Could you
> > > describe how you handle RCU patches across releases and if there is a
> > > fix for the 3.3-rcX issue Eric reported that is going into 3.3?
> > >
> > > I know you're quite busy, but I'd like to understand your thinking so I
> > > know what to expect going forward.
> >
> > Apologies for being slow, but could you please point me at the original
> > bug report that the old patch was designed to fix? My email filing
> > seems to have failed me in this case.
>
> Same thread I linked in my original email:
>
> https://lkml.org/lkml/2012/1/24/203
Thank you!
> > My guess is that the best short-term fix for Fedora is to disable the
> > warning, but I do need to see the original bug to work out if that really
> > is a prudent course of action.
>
> Honestly, I don't care from a Fedora perspective. I can do what I need
> to do there without too much trouble. I'm asking because afaik, upstream
> still has this problem. The thread gets a bit curvy but from what I can
> tell it resulted in the patch I highlighted as having issues. Maybe I
> overlooked something else that fixed Eric's problem?
"A bit curvy" is right -- which is why the fixes ended up at the end of
my large patch series for 3.4.
But after looking this over, Steven Rostedt's three-patch set should
suffice:
https://lkml.org/lkml/2012/2/7/231
The reason that mine are not needed is that the problematic code is
called -only- from idle, not from process context, and also that the
problematic code is tracing. My patch #45 is required for code that is
called from both process context and from idle. My patch #46 is required
for non-tracing uses of RCU from within the idle loop -- along with TBD
patches to wrap those uses of RCU in the RCU_NONIDLE() macro.
So again, in your particular case of x86's power-tracing features,
Steven Rostedt's three-patch series called out above should be all
that you need.
I have CCed Steven in case there is some prerequisite to his patch set.
Thanx, Paul
next prev parent reply other threads:[~2012-02-24 16:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-22 1:16 Large slowdown with 'x86: Avoid invoking RCU when CPU is idle' Josh Boyer
2012-02-22 1:32 ` Paul E. McKenney
2012-02-22 1:42 ` Josh Boyer
2012-02-24 14:40 ` Josh Boyer
2012-02-24 16:17 ` Paul E. McKenney
2012-02-24 16:27 ` Josh Boyer
2012-02-24 16:51 ` Paul E. McKenney [this message]
2012-02-24 17:20 ` Steven Rostedt
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=20120224165130.GB2399@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=jwboyer@redhat.com \
--cc=kernel-team@fedoraproject.org \
--cc=linux-kernel@vger.kernel.org \
--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 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.