Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754032AbcKUKsG (ORCPT ); Mon, 21 Nov 2016 05:48:06 -0500 Received: from mail-pf0-f177.google.com ([209.85.192.177]:35921 "EHLO mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753240AbcKUKsE (ORCPT ); Mon, 21 Nov 2016 05:48:04 -0500 Date: Mon, 21 Nov 2016 16:18:00 +0530 From: Viresh Kumar To: Peter Zijlstra Cc: Rafael Wysocki , Ingo Molnar , linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , Juri Lelli , Robin Randhawa , Steve Muckle , tkjos@google.com, Morten Rasmussen Subject: Re: [PATCH] cpufreq: schedutil: add up/down frequency transition rate limits Message-ID: <20161121104800.GC10014@vireshk-i7> References: <20161121100805.GB10014@vireshk-i7> <20161121101946.GI3102@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161121101946.GI3102@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1004 Lines: 27 On 21-11-16, 11:19, Peter Zijlstra wrote: > Urgh... > > > So no tunables and rate limits here at all please. > > During LPC we discussed the rampup and decay issues and decided that we > should very much first address them by playing with the PELT stuff. > Morton was going to play with capping the decay on the util signal. This > should greatly improve the ramp-up scenario and cure some other wobbles. > > The decay can be set by changing the over-all pelt decay, if so desired. > > Also, there was the idea of; once the above ideas have all been > explored; tying the freq ram rate to the power curve. > > So NAK on everything tunable here. Okay, as I told you on IRC, we already have a tunable: rate_limit_us for the schedutil governor which defines the minimum time before which the governor wouldn't try to update the frequency again. Perhaps 10-20 ms is the ideal value for that everyone is using. So eventually that should also die and we should get inputs from PELT stuff ? -- viresh