Messages in this thread | | | From | Joel Fernandes <> | Date | Mon, 30 Oct 2017 12:16:12 -0700 | Subject | Re: [PATCH RFC 4/5] sched/fair: Correct obsolete comment about cpufreq_update_util |
| |
Hi Viresh,
On Mon, Oct 30, 2017 at 2:22 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > You have prefixed most of the Cc'd names with "Cc: " somehow :)
Yeah :( What happened is I decided to play with using a text file to input --cc-cmd for git send-patch. Turns out I was too careless with forgetting to remove the "Cc: " prefix when I created the CC list. Anyway lesson learnt :)
> > On 28-10-17, 02:59, 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. > > We normally keep the column width as 72 in commit logs instead of 80, > as with 'git log' this is indented by a tab and then we would cross 80 > columns.
Ok, I'll keep that in mind and use 72 characters for future patches.
> >> Cc: Viresh Kumar <viresh.kumar@linaro.org> >> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> >> Cc: Ingo Molnar <mingo@redhat.com> >> Cc: Peter Zijlstra <peterz@infradead.org> >> Signed-off-by: Joel Fernandes <joelaf@google.com> >> --- >> 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 > > Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Thank you!
- Joel
| |