Proper scheduling in a multi-tasking environment is critical to the success
of a desktop OS. Linux, being mainly a server OS, is currently tuned to
scheduling defaults that may be appropriate only for the server scenario.
To enable Linux to play an effective role on the desktop, a more flexible
approach is necessary. An approach that would allow the end-User the
freedom to adjust the OS to the specific environment at hand.
So instead of forcing a one-size fits all approach on the end-User, would not
exporting sched.c tunables to the procfs present a flexible approach to the
scheduling dilemma?
All comments that have a vested interest in enabling Linux on the desktop are
most welcome, even if they describe other/better/smarter approaches.
Thanks!
--
Al
On Saturday 01 April 2006 00:23, Al Boldi wrote:
> Proper scheduling in a multi-tasking environment is critical to the success
> of a desktop OS. Linux, being mainly a server OS, is currently tuned to
> scheduling defaults that may be appropriate only for the server scenario.
>
> To enable Linux to play an effective role on the desktop, a more flexible
> approach is necessary. An approach that would allow the end-User the
> freedom to adjust the OS to the specific environment at hand.
>
> So instead of forcing a one-size fits all approach on the end-User, would
> not exporting sched.c tunables to the procfs present a flexible approach to
> the scheduling dilemma?
>
> All comments that have a vested interest in enabling Linux on the desktop
> are most welcome, even if they describe other/better/smarter approaches.
None of the current "tunables" have easily understandable heuristics. Even
those that appear to be obvious, like timselice, are not. While exporting
tunables is not a bad idea, exporting tunables that noone understands is not
really helpful. Even with heavy documentation, changes are not immediately
predictable, and parts of the scheduler "know" about the default tuning
values and they'd be broken by modifying them. Other scheduler designs, or
more infrastructure on the current one (like what Mike's working on) might
make some more obvious tunables. I've already discussed what I think in that
regard too on a similar email thread. Exporting them also incurs a not
insignificant cost.
Cheers,
Con
On Fri, 2006-03-31 at 17:23 +0300, Al Boldi wrote:
> Proper scheduling in a multi-tasking environment is critical to the success
> of a desktop OS. Linux, being mainly a server OS, is currently tuned to
> scheduling defaults that may be appropriate only for the server scenario.
>
> To enable Linux to play an effective role on the desktop, a more flexible
> approach is necessary. An approach that would allow the end-User the
> freedom to adjust the OS to the specific environment at hand.
>
> So instead of forcing a one-size fits all approach on the end-User, would not
> exporting sched.c tunables to the procfs present a flexible approach to the
> scheduling dilemma?
Nope, not the existing tunables anyway. The full effect of even a tiny
scheduler knob tweak is hard to predict even if you've studied the code
carefully. These knobs are just not generic enough to be exposed IMHO.
-Mike