[lkml]   [2004]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] O(1) Entitlement Based Scheduler

    Peter Williams wrote:

    > The O(1) Entitlement Based Scheduler places the equivalent restrictions
    > on setting task attributes (i.e. shares and caps) as are placed on using
    > nice and renice. I.e. ordinary users can only change settings on their
    > own processes and only if the change is more restricting than the
    > current setting. In particular, they cannot increase a task's shares
    > only decrease them, they can impose or reduce a cap but not release or
    > increase it and they can change a soft cap to a hard cap but cannot
    > change a hard cap to a soft cap.
    > Additionally, only root can change the scheduler's tuning parameters.
    > I hope this alleviates your concerns,

    I, for one, never had any such concerns. My concern was about the
    unpriveledged user begin unable to run certain applications under load
    without prior approval.

    Two philosophical points:

    1) Perhaps we are trying too hard to please everyone. As Linus said,
    perfect is the enemy of good. A good scheduler won't work perfectly for
    everyone's application, but it will work very well for the most
    important ones. Perhaps people writing schedulers should compete based
    on overall throughput and latency, rather than on how well it runs xmms
    (and other such apps).

    2) Perhaps certain apps like xmms are 'broken' can be rewritten to
    behave better with the new scheduler. For instance, more buffering,
    separating the mp3 decoding thread from the thread that feeds
    /dev/audio, more efficient decoder, a decoder that voluntarily sleeps
    when it's 'done enough', so that it doesn't get knocked down to a lower
    priority, a decoder that 'cheats' on audio quality just to maintain low
    CPU usage when it finds itself being preempted, etc.

    It bears mentioning that many applications work well with 2.4 because
    they evolved to work well with the 2.4 scheduler. The 2.6 scheduler is
    different. We shouldn't constrain 2.6 for the sake of old apps. Those
    old apps should be rewritten to adapt to the new environment. "Working
    well under 2.6" doesn't require any more adaptation than with 2.4, but
    it does require _different_ adaptation.

    This isn't to speak negatively of Con and Nick and others who have
    attempted to improve upon the 2.6 scheduler. If they can make old apps
    work well without impacting the potential that new apps can get out of
    2.6, then more power to them!

    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:01    [W:2.866 / U:0.108 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site