On Sun, 15 Apr 2007, Ingo Molnar wrote:
* Esben Nielsen <[email protected]> wrote:
I took a brief look at it. Have you tested priority inheritance?
yeah, you are right, it's broken at the moment, i'll fix it. But the
good news is that i think PI could become cleaner via scheduling
classes.
As far as I can see rt_mutex_setprio doesn't have much effect on
SCHED_FAIR/SCHED_BATCH. I am looking for a place where such a task
change scheduler class when boosted in rt_mutex_setprio().
i think via scheduling classes we dont have to do the p->policy and
p->prio based gymnastics anymore, we can just have a clean look at
p->sched_class and stack the original scheduling class into
p->real_sched_class. It would probably also make sense to 'privatize'
p->prio into the scheduling class. That way PI would be a pure property
of sched_rt, and the PI scheduler would be driven purely by
p->rt_priority, not by p->prio. That way all the normal_prio() kind of
complications and interactions with SCHED_OTHER/SCHED_FAIR would be
eliminated as well. What do you think?
Now I have not read your patch into detail. But agree it would be nice to
have it more "OO" and remove cross references between schedulers. But
first one should consider wether PI between SCHED_FAIR tasks or not is
usefull or not. Does PI among dynamic priorities make sense at all? I think it
does: On heavy loaded systems where a nice 19 might not get the CPU for
very long, a nice -20 task can be priority inverted for a very long
time.
But I see no need it taking the dynamic part of the effective priorities
into account. The current/old solution of mapping the static nice values
into a global priority index which can incorporate the two scheduler
classes is probably good enough - it just has to be "switched on" a again
:-)
But what about other scheduler classes which some people want to add in
the future? What about having a "cleaner design"?
My thought was to generalize the concept of 'priority' to be an
object (a struct prio) to be interpreted with help from a scheduler class
instead of globally interpreted integer.
int compare_prio(struct prio *a, struct prio *b)
{
if (a->sched_class->class_prio < b->sched_class->class_prio)
return -1;
if (a->sched_class->class_prio < b->sched_class->class_prio)
return +1;
return a->sched_class->compare_prio(a, b);
}
Problem 1: Performance.
Problem 2: Operations on a plist with these generalized priorities are not
bounded because the number of different priorites are not bounded.
Problem 2 could be solved by using a combined plist (for rt priorities)
and rbtree (for fair priorities) - making operations logarithmic just as
the fair scheduler itself. But that would take more memory for every
rtmutex.
I conclude that is too complicated and go on to the obvious idea:
Use a global priority index where each scheduler class get's it own
range (rt: 0-99, fair 100-139 :-). Let the scheduler class have a
function returning it instead of reading it directly from task_struct such
that new scheduler classes can return their own numbers.
Esben
Ingo
-
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]
