[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:0.039 / U:8.972 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site