From: Frederic Weisbecker <fweisbec@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Thoughts on this RCU idle entry/exit patch?
Date: Wed, 9 Oct 2013 16:56:19 +0200 [thread overview]
Message-ID: <20131009145614.GA20828@localhost.localdomain> (raw)
In-Reply-To: <20131008211218.GV5790@linux.vnet.ibm.com>
On Tue, Oct 08, 2013 at 02:12:18PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 08, 2013 at 10:34:28PM +0200, Frederic Weisbecker wrote:
> > So I wonder, do we want to continue to allow this nesting? I remember that DYNTICK_TASK_NEST_*
> > stuff is there to protects against non finishing interrupts on some archs (I also remember that
> > this, or at least a practical scenario for this, was hard to really define though :o)
> > But then wouldn't it involve other kind of scenario like this?
> >
> > rcu_irq_enter()
> > rcu_eqs_enter()
> > rcu_eqs_exit()
> > ...
> >
> > Anyway, that's just random thougths on further simplifications, in any case, this
> > patch looks good.
>
> Yep, if no task-level nesting is ever required, things could be a bit
> simpler. I would be a bit slow about making such a change, though.
> After all, the need to deal with Hotel California interrupts means that
> handling nesting isn't that big of a deal comparatively. ;-)
Right, well ideally it would be even best to fix the corner case(s) if there aren't
that many of them. I mean calling rcu_irq_exit() from the end of those half interrupts
I guess. It would make it much simpler than this complicated nesting handled on the core code.
But I agree there is a bit of unknown out there, so yeah lets be prudent :)
> May I add your Reviewed-by?
Sure, thanks!
next prev parent reply other threads:[~2013-10-09 14:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-07 15:39 Thoughts on this RCU idle entry/exit patch? Paul E. McKenney
2013-10-08 20:34 ` Frederic Weisbecker
2013-10-08 21:12 ` Paul E. McKenney
2013-10-09 14:56 ` Frederic Weisbecker [this message]
2013-10-09 15:08 ` 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=20131009145614.GA20828@localhost.localdomain \
--to=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
/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.