From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755366AbcESW7p (ORCPT ); Thu, 19 May 2016 18:59:45 -0400 Received: from mail-pa0-f48.google.com ([209.85.220.48]:34495 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755327AbcESW7o (ORCPT ); Thu, 19 May 2016 18:59:44 -0400 From: Steve Muckle X-Google-Original-From: Steve Muckle Date: Thu, 19 May 2016 15:59:39 -0700 To: "Rafael J. Wysocki" Cc: Steve Muckle , Peter Zijlstra , Ingo Molnar , Linux Kernel Mailing List , "linux-pm@vger.kernel.org" , Vincent Guittot , Morten Rasmussen , Dietmar Eggemann , Juri Lelli , Patrick Bellasi , Michael Turquette , Viresh Kumar , Srinivas Pandruvada , Len Brown Subject: Re: [PATCH 2/5] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs Message-ID: <20160519225939.GA15383@graphite.smuckle.net> References: <1462828814-32530-1-git-send-email-smuckle@linaro.org> <1462828814-32530-3-git-send-email-smuckle@linaro.org> <20160519184055.GD17223@graphite.smuckle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 On Thu, May 19, 2016 at 10:55:23PM +0200, Rafael J. Wysocki wrote: > >> > +static inline bool sugov_queue_remote_callback(struct sugov_policy *sg_policy, > >> > + int cpu) > >> > +{ > >> > + struct cpufreq_policy *policy = sg_policy->policy; > >> > + > >> > + if (!cpumask_test_cpu(smp_processor_id(), policy->cpus)) { > >> > >> This check is overkill for policies that aren't shared (and we have a > >> special case for them already). > > > > I don't see why it is overkill - > > Because it requires more computation, memory accesses etc than simply > comparing smp_processor_id() with cpu. Do you have a preference on how to restructure this? Otherwise I'll create a second version of sugov_update_commit, factoring out as much of it as I can into two inline sub-functions. ... > > > but it seems like an odd inconsistency for the governor to trace unchanged > > frequencies when fast switches are enabled but not otherwise. It'd be > > useful I think for profiling and tuning if the tracing was consistent. > > Well, fair enough. > > > This behavioral change is admittedly not part of the purpose of the > > patch and could be split out if needbe. > > No need to split IMO, but it might be prudent to mention that change > in behavior in the changelog. Will do. thanks, Steve