Re: [PATCH] RT: Add priority-queuing and priority-inheritance toworkqueue infrastructure

[Esben Nielsen]

On Wed, 1 Aug 2007, Daniel Walker wrote:

> On Wed, 2007-08-01 at 07:59 -0400, Gregory Haskins wrote:
> > On Tue, 2007-07-31 at 20:52 -0700, Daniel Walker wrote:
> >
> > > Here's a simpler version .. uses the plist data structure instead of the
> > > 100 queues, which makes for a cleaner patch ..
> >
> > Hi Daniel,
> >
> > I like your idea on the plist simplification a lot.  I will definitely
> > roll that into my series.
> >
> > I am not too psyched about using the rt_mutex_setprio() API directly,
> > however.  It seems broken to be calling that directly from non rt_mutex
> > code, IMHO.  Perhaps the PI subsystem should be broken out from the
> > rt_mutex code so it can be used generally?  There are other areas where
> > PI could potentially be used besides rt_mutex (this patch as a prime
> > example), so this might make sense.
>
> rt_mutex_setprio() is just a function. It was also designed specifically
> for PI , so it seems fairly sane to use it in other PI type
> situations ..
>
> Daniel

There seems to be a general need for boosting threads temporarely in a few 
places. HR-timers also have it, last time I checked. And preemptive RCU as 
well for boosting RCU readers. They all seems to deal with the same issues 
of correctly dealing with setting the priority and PI bosting from 
mutexes.

When boosting of RCU readers was discussed I came to the conclusion that 
the boosting property should be taken out of the of the rt_mutex module 
and instead be made into a sub-property of the scheduler:

task->pi_waiters should be replaced with task->prio_boosters being a 
pi_list of struct prio_booster representing something, which temporarely 
wants to boost a task.
A rt_mutex_waiter should of course contain a prio_booster which is added 
to owner->prio_boosters. A work queue element should contain a prio_booster.
When boosting a RCU reader a prio_booster is added  to the reader's 
prio_boosters.

Such a system will correctly deal with boosters going away in arbitrary 
order. Something which is not strait forward when each user of boosting is 
trying to do it on their own.

Esben

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