[lkml]   [2004]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH][plugsched 0/28] Pluggable cpu scheduler framework
    Con Kolivas wrote:
    > Ingo Molnar wrote:
    >> my main worry with this approach is not really overhead but the impact
    >> on scheduler development.
    >> no problem even under the current model, and it has happened before. We
    >> made the scheduler itself easily 'rip-out-able' in 2.6 by decreasing the
    >> junction points between the scheduler and the rest of the system. Also,
    >> the current scheduler is no way cast into stone, we could easily end up
    >> having a different interactivity code within the scheduler, as a result
    >> of the various 'get rid of the two arrays' efforts currently underway.
    > Do you honestly think with the current "2.6 forever" development process
    > that this is likely, even possible any more?

    That's a nutty problem... but suppose 2.7 opened tomorrow, how would
    you justify putting in a new scheduler even then? And how would you
    get enough testing to ensure a repeat of early 2.6 didn't happen again?

    I'd be very happy if we could figure out the answer to that question,
    but I'm afraid pluggable schedulers probably isn't it (unfortunately).

    > Given that fact, it means the current scheduler policy mechanism is
    > effectively set in stone. Do you think we can polish the current
    > scheduler enough to be, if not perfect, good enough for _every_ situation?

    Specialised users always have and always will do specialised
    modifications, that's no problem. But as much as I hate to say it
    (it's a good thing, I'd just like to be able to get nicksched in),
    it seems that the current scheduler *is* actually good enough for
    a general purpose operating system. At least the lack of complaints
    seems to indicate that.

    My proposal to the "how to get a new scheduler in" question is a set
    of pretty comprehensive controlled (blind of course), subjective tests
    with proper statistical analysis, to determine best behaviour... And
    I'm only half joking :(

    > Noone said that if we have a plugsched infrastructure that we should
    > instantly accept any scheduler.

    But so long as you don't have a compelling argument to _replace_
    the current scheduler, people who want to use other ones may as
    well just patch them in. By having multiple schedulers however,
    you don't IMO get too many benefits and a lot of downsides that
    Ingo pointed out.

    That said, if you were able to get a unanimous "yes" from Linus,
    Andrew, and Ingo then I wouldn't complain too loudly...
    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: 2005-03-22 14:07    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean