Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934016AbdCUT2d (ORCPT ); Tue, 21 Mar 2017 15:28:33 -0400 Received: from foss.arm.com ([217.140.101.70]:59548 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933926AbdCUT2a (ORCPT ); Tue, 21 Mar 2017 15:28:30 -0400 Date: Tue, 21 Mar 2017 19:28:19 +0000 From: Patrick Bellasi To: Peter Zijlstra Cc: "Rafael J. Wysocki" , Vincent Guittot , Linux PM , LKML , Srinivas Pandruvada , Viresh Kumar , Juri Lelli , Joel Fernandes , Morten Rasmussen , Ingo Molnar Subject: Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Message-ID: <20170321192819.GG11054@e110439-lin> References: <4366682.tsferJN35u@aspire.rjw.lan> <3429350.K2FUBgvcIK@aspire.rjw.lan> <20170321143842.GE11054@e110439-lin> <1844525.jBn1oKmyb6@aspire.rjw.lan> <20170321150820.GF11054@e110439-lin> <20170321151827.GW3093@worktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170321151827.GW3093@worktop> 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: 964 Lines: 30 On 21-Mar 16:18, Peter Zijlstra wrote: > On Tue, Mar 21, 2017 at 03:08:20PM +0000, Patrick Bellasi wrote: > > > And than we can move this bit into an inline function, something like e.g.: > > > > static inline bool sugov_this_cpu_is_busy() > > { > > return this_rq()->rd->overloaded > > } > > No, that's just entirely and utterly wrong. It being in rd means its > very much not about _this_ CPU in any way. You right (of course), we cannot really use "this_" in the name of a function with such a code. The suggestion here was at least to factor out whatever code we want to use to check if the current CPU has to be subject to a down-scaling constraint. However, using rd->overload is not the best option, for the many reasons you explained in your previous comment. Thus, we should probably stay with the idle time tracking solution initially proposed by Rafael. Sorry for the noise :-( -- #include Patrick Bellasi