From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932453AbdLOPkL (ORCPT ); Fri, 15 Dec 2017 10:40:11 -0500 Received: from mail-pf0-f195.google.com ([209.85.192.195]:38494 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932247AbdLOPj7 (ORCPT ); Fri, 15 Dec 2017 10:39:59 -0500 X-Google-Smtp-Source: ACJfBouKJ5ZQ94RPln1aP1vu59aeOxD1Vpk5gGqQ/Ojt+uqTfsEVCF/hnPjBDl951KYcs4PpDBk6GQ== From: Joel Fernandes To: linux-kernel@vger.kernel.org Cc: Joel Fernandes , Srinivas Pandruvada , Len Brown , "Rafael J. Wysocki" , Viresh Kumar , Ingo Molnar , Peter Zijlstra , Juri Lelli , Patrick Bellasi , Chris Redpath , Steve Muckle , Dietmar Eggemann , Vincent Guittot , Morten Ramussen , Frederic Weisbecker , Thomas Gleixner , Steven Rostedt , Saravana Kannan , Vikram Mulukutla , Rohit Jain , Atish Patra , Josef Bacik , EAS Dev , Android Kernel Subject: [PATCH 2/3] sched/fair: Correct obsolete comment about cpufreq_update_util Date: Fri, 15 Dec 2017 07:39:43 -0800 Message-Id: <20171215153944.220146-2-joelaf@google.com> X-Mailer: git-send-email 2.15.1.504.g5279b80103-goog In-Reply-To: <20171215153944.220146-1-joelaf@google.com> References: <20171215153944.220146-1-joelaf@google.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Since the remote cpufreq callback work, the cpufreq_update_util call can happen from remote CPUs. The comment about local CPUs is thus obsolete. Update it accordingly. Reviewed-by: Viresh Kumar Signed-off-by: Joel Fernandes --- kernel/sched/fair.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 2fe3aa853e4d..1b10821d8380 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3020,9 +3020,7 @@ static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq) /* * There are a few boundary cases this might miss but it should * get called often enough that that should (hopefully) not be - * a real problem -- added to that it only calls on the local - * CPU, so if we enqueue remotely we'll miss an update, but - * the next tick/schedule should update. + * a real problem. * * It will not get called when we go idle, because the idle * thread is a different class (!fair), nor will the utilization -- 2.15.1.504.g5279b80103-goog