From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751715AbdLSSCq (ORCPT ); Tue, 19 Dec 2017 13:02:46 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:60351 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751308AbdLSSCm (ORCPT ); Tue, 19 Dec 2017 13:02:42 -0500 Date: Tue, 19 Dec 2017 19:02:23 +0100 From: Peter Zijlstra To: Joel Fernandes Cc: linux-kernel@vger.kernel.org, Srinivas Pandruvada , Len Brown , "Rafael J. Wysocki" , Viresh Kumar , Ingo Molnar , 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: Re: [PATCH 2/3] sched/fair: Correct obsolete comment about cpufreq_update_util Message-ID: <20171219180223.4reegtvnmbge7dda@hirez.programming.kicks-ass.net> References: <20171215153944.220146-1-joelaf@google.com> <20171215153944.220146-2-joelaf@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171215153944.220146-2-joelaf@google.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 15, 2017 at 07:39:43AM -0800, Joel Fernandes wrote: > 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 Sure, ACK > --- > 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 >