Re: [RFC] sched.c : procfs tunables

[Bill Davidsen <davidsen@tmr.com>]

Al Boldi wrote:

> 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.
>  
Actually the lower HZ has something to do with that, and tuning 
swappiness can also help a lot.

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

bill davidsen <davidsen@tmr.com>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

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