From: Bill Huey (hui) <billh@gnuppy.monkey.org>
To: "Paul E. McKenney" <paulmck@us.ibm.com>
Cc: Esben Nielsen <nielsen.esben@googlemail.com>,
linux-kernel@vger.kernel.org, compudj@krystal.dyndns.org,
rostedt@goodmis.org, tglx@linutronix.de, mingo@elte.hu,
dipankar@in.ibm.com, rusty@au1.ibm.com,
"Bill Huey (hui)" <billh@gnuppy.monkey.org>
Subject: Re: [RFC, PATCH -rt] NMI-safe mb- and atomic-free RT RCU
Date: Thu, 27 Jul 2006 17:48:57 -0700 [thread overview]
Message-ID: <20060728004857.GA5096@gnuppy.monkey.org> (raw)
In-Reply-To: <20060728000231.GB1288@us.ibm.com>
On Thu, Jul 27, 2006 at 05:02:31PM -0700, Paul E. McKenney wrote:
> On Thu, Jul 27, 2006 at 12:53:56PM -0700, Bill Huey wrote:
> > On Thu, Jul 27, 2006 at 08:46:37AM -0700, Paul E. McKenney wrote:
> > > A possible elaboration would be to keep a linked list of tasks preempted
> > > in their RCU read-side critical sections so that they can be further
> > > boosted to the highest possible priority (numerical value of zero,
> > > not sure what the proper symbol is) if the grace period takes too many
> > > jiffies to complete. Another piece is priority boosting when blocking
> > > on a mutex from within an RCU read-side critical section.
> >
> > I'm not sure how folks feel about putting something like that in the
> > scheduler path since it's such a specialized cases. Some of the scheduler
> > folks might come out against this.
>
> They might well. And the resulting discussion might reveal a better
> way. Or it might well turn out that the simple approach of boosting
> to an intermediate level without the list will suffice.
Another thing. What you mention above is really just having a set of owners
for the read side and not really a preemption list tracking thing with RCU
and special scheduler path. The more RCU does this kind of thing the more
it's just like a traditional read/write lock but with more parallelism since
it's holding on to read side owners on a per CPU basis.
This was close to the idea I had for extending read/write locks to be more
parallel friendly for live CPUs, per CPU owner bins on individual cache lines
(I'll clarify if somebody asks), but the use of read/write locks is seldom
and in non-critical places, so just moving the code fully to RCU would be a
better solution. The biggest problem is to scan or denote to some central
structure (task struct, lock struct) when you were either in or out of the
reader section without costly atomic operations. That's a really huge cost
as you know already (OLS slides).
bill
next prev parent reply other threads:[~2006-07-28 0:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-26 0:17 [RFC, PATCH -rt] NMI-safe mb- and atomic-free RT RCU Paul E. McKenney
2006-07-27 1:39 ` Esben Nielsen
2006-07-27 1:39 ` Paul E. McKenney
2006-07-27 11:00 ` Esben Nielsen
2006-07-27 15:46 ` Paul E. McKenney
2006-07-27 19:53 ` Bill Huey
2006-07-28 0:02 ` Paul E. McKenney
2006-07-28 0:48 ` Bill Huey [this message]
2006-07-28 4:56 ` Paul E. McKenney
2006-07-28 11:14 ` Esben Nielsen
2006-07-28 15:25 ` Paul E. McKenney
2006-07-28 0:22 ` Esben Nielsen
2006-07-28 0:47 ` 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=20060728004857.GA5096@gnuppy.monkey.org \
--to=billh@gnuppy.monkey.org \
--cc=compudj@krystal.dyndns.org \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nielsen.esben@googlemail.com \
--cc=paulmck@us.ibm.com \
--cc=rostedt@goodmis.org \
--cc=rusty@au1.ibm.com \
--cc=tglx@linutronix.de \
/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