Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751739AbdG0HT4 (ORCPT ); Thu, 27 Jul 2017 03:19:56 -0400 Received: from mail-pg0-f50.google.com ([74.125.83.50]:37095 "EHLO mail-pg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751502AbdG0HTy (ORCPT ); Thu, 27 Jul 2017 03:19:54 -0400 Date: Thu, 27 Jul 2017 12:49:51 +0530 From: Viresh Kumar To: "Joel Fernandes (Google)" Cc: Rafael Wysocki , linux-pm@vger.kernel.org, Peter Zijlstra , Linux Kernel Mailing List , Ingo Molnar , Srinivas Pandruvada , Len Brown , smuckle.linux@gmail.com, eas-dev@lists.linaro.org, Joel Fernandes Subject: Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks Message-ID: <20170727071951.GM352@vireshk-i7> References: <20170727054635.GJ352@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1900 Lines: 44 On 26-07-17, 23:23, Joel Fernandes (Google) wrote: > Ok, but the "heavy" in init_entity_runnable_average means for load, > not the util_avg. The util_avg is what's used for frequency scaling > IIUC and is set to 0 in that function no? That's because the task isn't enqueued yet and so don't have any utilization. The last line of that routine is a comment which says: /* when this task enqueue'ed, it will contribute to its cfs_rq's load_avg */ But once the task is enqueued, this load_avg will get considered for sure :) > > The application was written by Steve (all credit goes to him) before > > he left Linaro, but I did test it with ftrace. What I saw with ftrace > > was that the freq isn't reevaluated for almost an entire tick many > > times because we enqueued the task remotely. And that changes with > > this series. > > > >> > The reason being that this patchset only targets a corner case, where > >> > following are required to be true to improve performance and that > >> > doesn't happen too often with these tests: > >> > > >> > - Task is migrated to another CPU. > >> > - The task has maximum demand initially, and should take the CPU to > >> > >> Just to make the cover-letter more clear and also confirming with you > >> I understand the above usecase, maybe in the future this can reworded > >> from "initially" to "before the migration" and "take the CPU" to "take > >> the target CPU of the migration" ? > > > > I can reword it a bit, but the test case wasn't really migrating > > anything and was looking only at the initial loads. > > Ok, I wasn't talking about the synthetic test in the second part of my > email above but about the explanation you gave about Galleryfling > improvement (that the migration of a task with high utilization > doesn't update the target frequency) which makes sense to me so we are > on the same page about that. Okay, great. -- viresh