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

[Bill Huey (hui) <billh@gnuppy.monkey.org>]

On Fri, Jul 28, 2006 at 08:52:20AM -0700, Paul E. McKenney wrote:
> I must defer to Ingo, Thomas, and Steve Rostedt on what the right thing
> to do is here, but I do much appreciate the pointers!
> 
> If I understand what you are getting at, this is what I would need to
> do to in order to have a synchronize_rcu() priority-boost RCU readers?
> Or is this what I need to legitimately priority-boost RCU readers in
> any case (for example, to properly account for other boosting and
> deboosting that might happen while the RCU reader is priority boosted)?
> 
> Here are the RCU priority-boost situations I see:
> 
> 1.	"Out of nowhere" RCU-reader priority boost.  This is what
> 	the patch I submitted was intended to cover.  If I need your
> 	prio_booster struct in this case, then I would need to put
> 	one in the task structure, right?
> 
> 	Would another be needed to handle a second boost?  My guess
> 	is that the first could be reused.

What is that ? like randomly boosting without tracking which thread is
inside an RCU critical section ?

> 2.	RCU reader boosting a lock holder.  This ends up being a
> 	combination of #1 (because the act of blocking on a lock implies
> 	an "out of nowhere" priority boost) and normal lock boosting.

Lock holder as in mutex held below and RCU critical section ?

> 3.	A call_rcu() or synchronize_rcu() boosting all readers.  I am
> 	not sure we really need this, but in case we do...  One would
> 	need an additional prio_booster for each task to be boosted,
> 	right?  This would seem to require an additional prio_booster
> 	struct in each task structure.
 
This needs a notion of RCU read side ownership to boost those preempted
threads.

> Or am I off the mark here?

The scary thing about what you're doing is that all of the techniques
you've named (assuming that I understand you correctly) requires a
notion of an owner and ownership tracking. That's just going to kill
RCU read side performance if you do that whether it be a list per reader
or something else like that. It's a tough problem.

Don't know what to think about it other than some kind of tracking or
boosting logic in the per CPU run queue or the task struct itself during
the boost operation. But you're still stuck with the problem of what
to boost and how to find that out during an RCU sync side. It's still
an ownership problem unless Esben can think of another way of getting
around that problem.

That's why I suggested a priority ceiling or per CPU priority threshold
tracking (+ CPU binding) the priority of the irq-threads and stuff. It's
a simple hack to restore the cheesy preempt count stuff without having
to revert to invasive ownership tracking for each reader.

It's just an idea. Maybe it'll be useful to you.

bill

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