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