Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757463AbcCCRNm (ORCPT ); Thu, 3 Mar 2016 12:13:42 -0500 Received: from foss.arm.com ([217.140.101.70]:38675 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751923AbcCCRNj (ORCPT ); Thu, 3 Mar 2016 12:13:39 -0500 Date: Thu, 3 Mar 2016 17:14:43 +0000 From: Juri Lelli To: Peter Zijlstra Cc: "Rafael J. Wysocki" , Vincent Guittot , "Rafael J. Wysocki" , Linux PM list , Steve Muckle , ACPI Devel Maling List , Linux Kernel Mailing List , Srinivas Pandruvada , Viresh Kumar , Michael Turquette Subject: Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Message-ID: <20160303171443.GZ18792@e106622-lin> References: <2495375.dFbdlAZmA6@vostro.rjw.lan> <1842158.0Xhak3Uaac@vostro.rjw.lan> <20160303122030.GN6356@twins.programming.kicks-ass.net> <20160303163735.GS6356@twins.programming.kicks-ass.net> <20160303165544.GY18792@e106622-lin> <20160303165640.GT6356@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160303165640.GT6356@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 844 Lines: 19 On 03/03/16 17:56, Peter Zijlstra wrote: > On Thu, Mar 03, 2016 at 04:55:44PM +0000, Juri Lelli wrote: > > On 03/03/16 17:37, Peter Zijlstra wrote: > > > But given the platform's cpuidle information, maybe coupled with an avg > > > idle est, we can compute the benefit of race-to-idle and over provision > > > based on that, right? > > > > > > > Shouldn't this kind of considerations be a scheduler thing? I'm not > > really getting why we want to put more "intelligence" in a new governor. > > Also, if I understand Ingo's point correctly, I think we want to make > > this kind of policy decisions inside the scheduler. > > Well sure, put it in kernel/sched/cpufreq.c or wherever. My point was > more that we don't have to guess/hardcode race-to-idle assumptions but > can actually calculate some of that. > Right, thanks for clarifying!