From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750912AbdDBEiP (ORCPT ); Sun, 2 Apr 2017 00:38:15 -0400 Received: from mail-qt0-f179.google.com ([209.85.216.179]:35427 "EHLO mail-qt0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750800AbdDBEiN (ORCPT ); Sun, 2 Apr 2017 00:38:13 -0400 MIME-Version: 1.0 In-Reply-To: References: <1514608.eWxQqcMBcc@aspire.rjw.lan> <20170331102223.GS19929@e106622-lin> <6978951.cfP8K2rCI0@aspire.rjw.lan> From: Andres Oportus Date: Sat, 1 Apr 2017 21:38:12 -0700 Message-ID: Subject: Re: [RFC/RFT][PATCH] cpufreq: schedutil: Reduce frequencies slower To: "Rafael J. Wysocki" Cc: Juri Lelli , Linux PM , LKML , Peter Zijlstra , Srinivas Pandruvada , Viresh Kumar , Vincent Guittot , Patrick Bellasi , Joel Fernandes , Morten Rasmussen , John Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 1, 2017 at 7:03 PM, Rafael J. Wysocki wrote: > On Sun, Apr 2, 2017 at 1:29 AM, Andres Oportus > wrote: >> On Sat, Apr 1, 2017 at 1:39 PM, Andres Oportus >> wrote: >>> Hi Rafael, Juri, > > [cut] > >>>> >>>> > As we discussed at the last LPC, having an energy model handy and use >>>> > that to decide how quickly to ramp up or slow down seems the desirable >>>> > long term solution, but we probably need something (as you are >>>> > proposing) until we get there. >>>> >>>> Well, we definitely need something to address real use cases, like the one >>>> that >>>> I responded to with this patch. :-) >>> >>> I don't know the history/intent behind schedutil rate limiting, but if we > > Basically, the hardware cannot be requested to change the frequency > too often as that would be too expensive in general. Expensiveness of changing the frequency too often is one of the reasons we need to have down throttle in Android, but we can't have this value also slow down the frequency increases (so up throttle being equal to down throttle is bad for us) which would affect interactivity/response-time. > >>> make it to be only "down" as Juri mentioned we would not be adding a new >>> tunable but rather changing the current one to be more restricted (maybe >>> some renaming would be in order if this is done), this would provide >>> hysteresis to reduce this problem without locking the amount of the >>> hysteresis which may not work for all platforms. I also agree that "it is >>> difficult to imagine that the same values will always be suitable for every >>> workload", but without any value to control the whole system, we get nothing >>> in between. Ultimately I also think we should solve the hysteresis problem >>> at the root, i.e. the input to the governor in the form of util/load that >>> has not only hysteresis and energy model, but also any other behavioral >>> inputs built-in. > > That's long-term, though, and besides knobs only help if users change > the defaults. From my experience they usually don't do that. Agreed that it is long term. Regarding knobs, we are already tuning the down throttle value for Android (we currently do 50ms down for the similar knob in schedfreq). > > Thanks, > Rafael Thanks, Andres