lkml.org 
[lkml]   [2007]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
    On Sun, 15 Apr 2007, Ingo Molnar wrote:

    >
    > * Esben Nielsen <nielsen.esben@googlemail.com> 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 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/

    \
     
     \ /
      Last update: 2007-04-16 09:19    [W:4.102 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site