From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753589AbdF2VYB (ORCPT <rfc822;w@1wt.eu>);
        Thu, 29 Jun 2017 17:24:01 -0400
Received: from mga01.intel.com ([192.55.52.88]:17848 "EHLO mga01.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751776AbdF2VYA (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 29 Jun 2017 17:24:00 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.40,282,1496127600"; 
   d="scan'208";a="1166340521"
Message-ID: <1498771438.7952.118.camel@linux.intel.com>
Subject: Re: [PATCH V2 3/4] intel_pstate: Ignore scheduler cpufreq callbacks
 on remote CPUs
From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
        Rafael Wysocki <rjw@rjwysocki.net>, Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>, Len Brown <lenb@kernel.org>
Cc: linux-pm@vger.kernel.org, Vincent Guittot <vincent.guittot@linaro.org>,
        linux-kernel@vger.kernel.org, smuckle.linux@gmail.com,
        juri.lelli@arm.com, Morten.Rasmussen@arm.com, patrick.bellasi@arm.com,
        eas-dev@lists.linaro.org
Date: Thu, 29 Jun 2017 14:23:58 -0700
In-Reply-To: <a33ba3746dacce67a7c2e17b64e54ee89f64a3bc.1498712046.git.viresh.kumar@linaro.org>
References: <cover.1498712046.git.viresh.kumar@linaro.org>
         <a33ba3746dacce67a7c2e17b64e54ee89f64a3bc.1498712046.git.viresh.kumar@linaro.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 2017-06-29 at 10:56 +0530, Viresh Kumar wrote:
> From: Steve Muckle <smuckle.linux@gmail.com>
> 
> In preparation for the scheduler cpufreq callback happening on remote
> CPUs, check for this case in intel_pstate which currently requires
> the
> callback run on the local CPU. Such callbacks are ignored for now.
Is it possible that we miss a chance to calculate load periodically at
a predefined interval (10ms default), because the callback happened on
a different CPU?

Thanks,
Srinivas

> 
> Signed-off-by: Steve Muckle <smuckle.linux@gmail.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  drivers/cpufreq/intel_pstate.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/cpufreq/intel_pstate.c
> b/drivers/cpufreq/intel_pstate.c
> index 4ce501148790..7a2a8ee579ef 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1755,6 +1755,9 @@ static void intel_pstate_update_util(struct
> update_util_data *data, u64 time,
>  	struct cpudata *cpu = container_of(data, struct cpudata,
> update_util);
>  	u64 delta_ns;
>  
> +	if (smp_processor_id() != data->cpu)
> +		return;
> +
>  	if (flags & SCHED_CPUFREQ_IOWAIT) {
>  		cpu->iowait_boost = int_tofp(1);
>  	} else if (cpu->iowait_boost) {