Re: [RFC] sched.c : procfs tunables

[Al Boldi <a1426z@gawab.com>]

Con Kolivas wrote:
> On Monday 03 April 2006 21:59, Al Boldi wrote:
> > Con Kolivas wrote:
> > > 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?
>
> You're assuming there is some meaningful relationship between changes in
> cpu/mem/ctxt performance and these tunables, which isn't the case.
> Furthermore if this was the case, noone understands it, can predict it or
> know how to tune it. Just saying "autotune it" doesn't really tell us how
> exactly the change those tunables in relation to the other variables.
> Since Mike and I understand them reasonably well I think we'd both agree
> that there is no meaningful association.

After playing w/ these tunables it occurred to me that they are really only 
deadline limits, w/ a direct relation to cpu/mem/ctxt perf.

i.e timeslice=1 on i386sx means something other than timeslice=1 on amd64

It follows that w/o autotuning, the static default values have to be selected 
to allow for a large underlying perf range w/ a preference for the high 
range.  This is also the reason why 2.6 feels really crummy on low perf 
ranges.

Autotuning the default values would allow to tighten this range specific to 
the hw used, thus allowing for a smoother desktop experience.

Thanks!

--
Al

-
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/