[lkml]   [2007]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] RT: Add priority-queuing and priority-inheritance to workqueue infrastructure

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

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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-08-01 23:51    [W:0.066 / U:30.256 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site