Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754056AbcDMQHN (ORCPT ); Wed, 13 Apr 2016 12:07:13 -0400 Received: from mail-lf0-f66.google.com ([209.85.215.66]:36081 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753940AbcDMQHL (ORCPT ); Wed, 13 Apr 2016 12:07:11 -0400 MIME-Version: 1.0 In-Reply-To: References: <56F97856.4040804@arm.com> <56F98832.3030207@linaro.org> <20160330193544.GD407@worktop> <56FC807C.80204@linaro.org> <20160331073743.GF3408@twins.programming.kicks-ass.net> <56FD95EE.6090007@linaro.org> <20160401092019.GN3430@twins.programming.kicks-ass.net> <570BFAE2.4080301@linaro.org> <20160413000824.GB22643@graphite.smuckle.net> Date: Wed, 13 Apr 2016 18:07:09 +0200 X-Google-Sender-Auth: rR0POPEkd9uxetnltu8IrYrQBdA Message-ID: Subject: Re: [PATCH 1/2] sched/fair: move cpufreq hook to update_cfs_rq_load_avg() From: "Rafael J. Wysocki" To: Steve Muckle Cc: Peter Zijlstra , Dietmar Eggemann , Ingo Molnar , Linux Kernel Mailing List , "linux-pm@vger.kernel.org" , Vincent Guittot , Morten Rasmussen , Juri Lelli , Patrick Bellasi , Michael Turquette Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2445 Lines: 57 On Wed, Apr 13, 2016 at 6:05 PM, Rafael J. Wysocki wrote: > On Wed, Apr 13, 2016 at 6:48 AM, Rafael J. Wysocki wrote: >> On Wed, Apr 13, 2016 at 2:08 AM, Steve Muckle wrote: >>> On Tue, Apr 12, 2016 at 04:29:06PM +0200, Rafael J. Wysocki wrote: >>>> This is rather fundamental. >>>> >>>> For example, if you look at cpufreq_update_util(), it does this: >>>> >>>> data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data)); >>>> >>>> meaning that it will run the current CPU's utilization update >>>> callback. Of course, that won't work cross-CPU, because in principle >>>> different CPUs may use different governors and therefore different >>>> util update callbacks. >>> >>> Will something like the attached (unfinished patches) work? It seems >>> to for me, but I haven't tested it much beyond confirming the hook is >>> working on remote wakeups. >> >> No, they are not sufficient. >> >> First of all, you need to take all of the governors into account and >> they all make assumptions about updates being run on the CPU being >> updated. >> >> That should be easy to take into account for ondemand/conservative, >> but intel_pstate is a different story. >> >>> I'm relying on the previous comment that it's up to cpufreq drivers to >>> run stuff on the target policy's CPUs if the driver needs that. >> >> That's not the case for the fast frequency switching though, which has >> to happen on the CPU running the code. >> >>> There's still some more work, fixing up some more smp_processor_id() >>> usage in schedutil, but it should be easy (trace, slow path irq_work >>> target). >>> >>>> If you want to do remote updates, I guess that will require an >>>> irq_work to run the update on the target CPU, but then you'll probably >>>> want to neglect the rate limit on it as well, so it looks like a >>>> "need_update" flag in struct update_util_data will be useful for that. >>> >>> Why is it required to run the update on the target CPU? >> >> The fast switching and intel_pstate are the main reason. >> >> They both have to write to registers of the target CPU and the code to >> do that needs to run on that CPU. > > And these two seem to be the only interesting cases for you, because > if you need to work for the worker thread to schedule to eventually s/work/wait/ (sorry) > change the CPU frequency for you, that will defeat the whole purpose > here.