From mboxrd@z Thu Jan 1 00:00:00 1970 From: Con Kolivas Subject: Re: [RFC] sched.c : procfs tunables Date: Mon, 3 Apr 2006 22:21:31 +1000 Message-ID: <200604032221.32461.kernel@kolivas.org> References: <200603311723.49049.a1426z@gawab.com> <200604010044.09185.kernel@kolivas.org> <200604031459.43105.a1426z@gawab.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200604031459.43105.a1426z@gawab.com> Content-Disposition: inline Sender: linux-smp-owner@vger.kernel.org List-Id: Content-Type: text/plain; charset="us-ascii" To: Al Boldi Cc: linux-kernel@vger.kernel.org, linux-smp@vger.kernel.org, Mike Galbraith 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. Cheers, Con