Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754341AbdDKLOt (ORCPT ); Tue, 11 Apr 2017 07:14:49 -0400 Received: from mail-pf0-f177.google.com ([209.85.192.177]:32908 "EHLO mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753141AbdDKLOr (ORCPT ); Tue, 11 Apr 2017 07:14:47 -0400 Date: Tue, 11 Apr 2017 16:44:43 +0530 From: Viresh Kumar To: "Rafael J. Wysocki" Cc: Linux PM , Juri Lelli , LKML , Peter Zijlstra , Srinivas Pandruvada , Vincent Guittot , Patrick Bellasi , Joel Fernandes , Morten Rasmussen , Brendan Jackman Subject: Re: [RFC/RFT][PATCH 1/2] cpufreq: schedutil: Use policy-dependent transition delays Message-ID: <20170411111443.GE13627@vireshk-i7> References: <3498238.liCqOyIkGA@aspire.rjw.lan> <2407280.n9qVSLCrF5@aspire.rjw.lan> <71055380.gdY33coAtF@aspire.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71055380.gdY33coAtF@aspire.rjw.lan> 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: 993 Lines: 28 On 11-04-17, 00:20, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Make the schedutil governor take the initial (default) value of the > rate_limit_us sysfs attribute from the (new) transition_delay_us > policy parameter (to be set by the scaling driver). > > That will allow scaling drivers to make schedutil use smaller default > values of rate_limit_us and reduce the default average time interval > between consecutive frequency changes. > > Make intel_pstate set transition_delay_us to 500. > > Signed-off-by: Rafael J. Wysocki > --- > > This is a replacement for https://patchwork.kernel.org/patch/9671831/ > > --- > drivers/cpufreq/intel_pstate.c | 2 ++ > include/linux/cpufreq.h | 7 +++++++ > kernel/sched/cpufreq_schedutil.c | 15 ++++++++++----- > 3 files changed, 19 insertions(+), 5 deletions(-) Should we use this new value for the ondemand/conservative governors as well? -- viresh