lkml.org 
[lkml]   [2006]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] sched.c : procfs tunables
Date
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/

\
 
 \ /
  Last update: 2006-04-04 15:32    [W:1.326 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site