linux-kernel - Re: [RFC, PATCH, -rt] Early prototype RCU priority-boost patch

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] [day] [month] [year] [list]

Message-ID: <20060731222219.GA12960@gnuppy.monkey.org>
Date:	Mon, 31 Jul 2006 15:22:19 -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, tglx@...utronix.de,
	rostedt@...dmis.org, dipankar@...ibm.com, mingo@...e.hu,
	tytso@...ibm.com, dvhltc@...ibm.com,
	"Bill Huey (hui)" <billh@...ppy.monkey.org>
Subject: Re: [RFC, PATCH, -rt] Early prototype RCU priority-boost patch

On Mon, Jul 31, 2006 at 07:38:50AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 28, 2006 at 07:50:37PM -0700, Bill Huey wrote:
> > The problem here is that I can't see how it's going to boost the thread
> > if the things doing the RCU sync can't track the list of readers. It
> > might be record in the trask struct, now what ?
> 
> The first boost is performed by the task itself the first time there
> is a preemption attempt (or the first time it blocks on a mutex), so
> no need to track the list of readers in that case.  The trick is that
> there is no benefit to boosting someone who is already running -- we
> only need to boost the first time they are considering blocking.
> 
> If there is a need for a second "boost to the sky" in case of excessively
> delayed grace period (or to provide deterministic synchronize_rcu()
> latency), then we need a list only of those RCU readers who have attempted
> to block at least once thus far in their current RCU read-side critical
> section.  But I was putting this off until I get the simple case right.
> Cowardly of me, I know!  ;-)
 
Ok, I see what you're talking about.

> Finally found Steve Rostedt's PI document (in 2.6.18-rc2), very helpful
> (though I suppose I should reserve judgement until after I get this
> working...)
> 
> > It's a possible solution to a rather difficult problem. What do you think ?
> > too much of a hack ?
> 
> I am not sure -- seems to be a dual approach to boosting the RCU reader's
> priority in the preemption case.  I suspect that a real priority boost
> would still be needed in the case where the RCU reader blocks on a mutex,
> since we need the priority inheritance to happen in that case, right?

This is unfortunately true. It maybe that my suggestion isn't going to
work in this scenario. I'll have to think about this more. I think that
either way you still have to extract information somewhere that there is
you're in a live RCU reader section anyways, either through an RCU read
side counter or some kind of mechanism like that (boosted priority or
ceiling can denote some use of RCU, as in a some kind of count, but this
is getting more complicated and remotely less useful) and still take tha
into account when you do priority inheritance.

I'll have to think about this more, but you are probably completely
correct and it might not be possible to priority boost an RCU read side
without some kind of explicit reader tracking in the task struct.

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/