Messages in this thread | | | Date | Thu, 06 Apr 2006 22:47:42 -0400 | From | Bill Davidsen <> | Subject | Re: [RFC] sched.c : procfs tunables |
| |
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/
| |