lkml.org 
[lkml]   [2007]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
    Date

    > There's a distinction between giving it more cpu and giving it higher
    > priority: the important part about having high priority is getting low
    > latency access to the cpu when its needed.

    I agree. Tasks that voluntarily relinquish their timeslices should get lower
    latency compared to other processes at the same static priority.

    > This really seems like the wrong approach to me. The implication here
    > and in other mails is that fairness is an inherently good thing which
    > should obviously take preference over any other property.

    Yes, that is the implication. The alternative to fairness is arbitrary
    unfairness. "Rational unfairness" is a form of fairness.

    > The old unix-style dynamic priority scheme was designed to give
    > interactive processes high priorities, by using the observation that
    > "interactive" means "spends a lot of time blocked waiting for input".
    > That model of interactive is way too simple now, and the attempts to try
    > an find an equivalent heuristic have been flawed and lead to - in some
    > cases - wildly bad behaviours. I'm guessing the emphasis on "fairness"
    > is in reaction to this, which is fair enough.

    I don't think it makes sense for the scheduler to look for some hint that
    the user would prefer a task to get more CPU and try to give it more. That's
    what 'nice' is for.

    > But saying that the user needs to explicitly hold the schedulers hand
    > and nice everything to tell it how to schedule seems to be an abdication
    > of duty, an admission of failure. We can't expect users to finesse all
    > their processes with nice, and it would be a bad user interface to ask
    > them to do so.

    Then you will always get cases where the scheduler does not do what the user
    wants because the scheduler does not *know* what the user wants. You always
    have to tell a computer what you want it to do, and the best it can do is
    faithfully follow your request.

    I think it's completely irrational to ask for a scheduler that automatically
    gives more CPU time to CPU hogs.

    > And if someone/distro *does* go to all the effort of managing how to get
    > all the processes at the right nice levels, you have this big legacy
    > problem where you're now stuck keeping all those nice values meaningful
    > as you continue to develop the scheduler. Its bad enough to make them
    > do the work in the first place, but its worse if they need to make it a
    > kernel version dependent function.

    I agree. I'm not claiming to have the perfect solution. Let's not let the
    perfect be the enemy of the good though.

    DS


    -
    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-03-13 21:01    [W:0.023 / U:58.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site