Re: [RFC] sched.c : procfs tunables
Bill Davidsen <[email protected]>
| Newsgroups | gmane.linux.smp,gmane.linux.kernel |
|---|---|
| Organization | TMR Associates Inc, Schenectady NY |
| Message-ID | <[email protected]> |
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 <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-smp" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html