linux-kernel - Re: [RFC, PATCH -rt] NMI-safe mb- and atomic-free RT RCU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 27 Jul 2006 17:48:57 -0700
From:	Bill Huey (hui) <billh@...ppy.monkey.org>
To:	"Paul E. McKenney" <paulmck@...ibm.com>
Cc:	Esben Nielsen <nielsen.esben@...glemail.com>,
	linux-kernel@...r.kernel.org, compudj@...stal.dyndns.org,
	rostedt@...dmis.org, tglx@...utronix.de, mingo@...e.hu,
	dipankar@...ibm.com, rusty@....ibm.com,
	"Bill Huey (hui)" <billh@...ppy.monkey.org>
Subject: Re: [RFC, PATCH -rt] NMI-safe mb- and atomic-free RT RCU

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/