Con Kolivas wrote:
> 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.
Couldn't this be fixed with an autotuning module based on cpu/mem/ctxt
performance?
Mike Galbraith wrote:
> 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.
Are you implying that the code is built around these tunables rather than
using them?
Thanks!
--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
