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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
