From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753900AbbG0Not (ORCPT ); Mon, 27 Jul 2015 09:44:49 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:57765 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751261AbbG0Nm5 (ORCPT ); Mon, 27 Jul 2015 09:42:57 -0400 From: "Rafael J. Wysocki" To: Linux PM list Cc: Viresh Kumar , Linux Kernel Mailing List , Russell King - ARM Linux Subject: [PATCH 5/7] cpufreq: Do not update related_cpus on every policy activation Date: Mon, 27 Jul 2015 16:06:54 +0200 Message-ID: <3102455.P3lingtaHD@vostro.rjw.lan> User-Agent: KMail/4.11.5 (Linux/4.1.0-rc5+; KDE/4.11.5; x86_64; ; ) In-Reply-To: <3874727.Jpay9zgokc@vostro.rjw.lan> References: <7868353.pEStq1MJ2a@vostro.rjw.lan> <3874727.Jpay9zgokc@vostro.rjw.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki The related_cpus mask includes CPUs whose cpufreq_cpu_data per-CPU pointers have been set to the given policy. Since those pointers are only set at the policy creation time and unset when the policy is deleted, the related_cpus should not be updated between those two operations. For this reason, avoid updating it whenever the first of the "related" CPUs goes online. Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/cpufreq.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) Index: linux-pm/drivers/cpufreq/cpufreq.c =================================================================== --- linux-pm.orig/drivers/cpufreq/cpufreq.c +++ linux-pm/drivers/cpufreq/cpufreq.c @@ -1251,12 +1251,12 @@ static int cpufreq_add_dev(struct device down_write(&policy->rwsem); - /* related cpus should atleast have policy->cpus */ - cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus); - - /* Remember which CPUs have been present at the policy creation time. */ - if (!recover_policy) + if (!recover_policy) { + /* related_cpus should at least include policy->cpus. */ + cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus); + /* Remember CPUs present at the policy creation time. */ cpumask_and(policy->real_cpus, policy->cpus, cpu_present_mask); + } /* * affected cpus must always be the one, which are online. We aren't