From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751638AbdJ1KAt (ORCPT ); Sat, 28 Oct 2017 06:00:49 -0400 Received: from mail-qt0-f194.google.com ([209.85.216.194]:50344 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750998AbdJ1KAK (ORCPT ); Sat, 28 Oct 2017 06:00:10 -0400 X-Google-Smtp-Source: ABhQp+Se/Zbeo0ly4DtUSOoGUyvS6UtHCHBK3XOlxzFyToID6MDki1ck/tJewu2Myq3E79GwcU9j1w== From: Joel Fernandes To: linux-kernel@vger.kernel.org Cc: Joel Fernandes , Viresh Kumar , "Rafael J . Wysocki" , Ingo Molnar , Peter Zijlstra , "Cc: Srinivas Pandruvada" , "Cc: Len Brown" , "Cc: Juri Lelli" , "Cc: Patrick Bellasi" , "Cc: Steve Muckle" , "Cc: Brendan Jackman" , "Cc: Chris Redpath" , "Cc: Atish Patra" , "Cc: Dietmar Eggemann" , "Cc: Vincent Guittot" , "Cc: Morten Ramussen" , "Cc: Frederic Weisbecker" , "Cc: Thomas Gleixner" , "Cc: EAS Dev" , "Cc: Android Kernel" Subject: [PATCH RFC 4/5] sched/fair: Correct obsolete comment about cpufreq_update_util Date: Sat, 28 Oct 2017 02:59:40 -0700 Message-Id: <20171028095941.4773-5-joelaf@google.com> X-Mailer: git-send-email 2.15.0.rc2.357.g7e34df9404-goog In-Reply-To: <20171028095941.4773-1-joelaf@google.com> References: <20171028095941.4773-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. Cc: Viresh Kumar Cc: Rafael J. Wysocki Cc: Ingo Molnar Cc: Peter Zijlstra 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 4c06e52935d3..5c49fdb4c508 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3018,9 +3018,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.0.rc2.357.g7e34df9404-goog