From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH] cpufreq: schedutil: add up/down frequency transition rate limits Date: Mon, 21 Nov 2016 15:43:43 +0100 Message-ID: <20161121144343.GH3092@twins.programming.kicks-ass.net> References: <20161121100805.GB10014@vireshk-i7> <20161121101946.GI3102@twins.programming.kicks-ass.net> <20161121121432.GK24383@e106622-lin> <20161121122622.GC3092@twins.programming.kicks-ass.net> <20161121135308.GN24383@e106622-lin> <20161121141728.GF3092@twins.programming.kicks-ass.net> <20161121143727.GO24383@e106622-lin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20161121143727.GO24383@e106622-lin> Sender: linux-kernel-owner@vger.kernel.org To: Juri Lelli Cc: Viresh Kumar , Rafael Wysocki , Ingo Molnar , linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , Robin Randhawa , Steve Muckle , tkjos@google.com, Morten Rasmussen List-Id: linux-pm@vger.kernel.org On Mon, Nov 21, 2016 at 02:37:27PM +0000, Juri Lelli wrote: > On 21/11/16 15:17, Peter Zijlstra wrote: > > Not sure I follow. So by limiting decay to the task value, the moment we > > add it back to the accumulated signal (wakeup), the accumulated signal > > jumps up quickly and ramp-up is achieved. > > > > This is true, but it seems that this potentially spiky behaviour > (which in general depends on tasks composition and periodicity) might > affect power savings (as in you don't generally want to switch between > high and low freqs too often). So that's why I was just thinking that > some sort of smoothing applied to the signal schedutil uses might help. Hurm.. so during LPC it was said that fast ramp-up was desired. Note that we'll not ramp down this fast, the accumulated signal will decay slowly as per blocked-load PELT rules. So only ramp-up is spiky, but that is what was desired AFAIU.