Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754814AbcDMSGM (ORCPT ); Wed, 13 Apr 2016 14:06:12 -0400 Received: from mail-pf0-f182.google.com ([209.85.192.182]:33296 "EHLO mail-pf0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753937AbcDMSGL (ORCPT ); Wed, 13 Apr 2016 14:06:11 -0400 Subject: Re: [PATCH 1/2] sched/fair: move cpufreq hook to update_cfs_rq_load_avg() To: "Rafael J. Wysocki" 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> 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 From: Steve Muckle X-Enigmail-Draft-Status: N1110 Message-ID: <570E8A8F.2030109@linaro.org> Date: Wed, 13 Apr 2016 11:06:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1565 Lines: 40 On 04/13/2016 09:07 AM, Rafael J. Wysocki wrote: >>>>> 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. Have you added rate limiting at the hook level that I missed? I thought it was just inside schedutil. >>>> >>>> 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. Ok thanks, I'll take another look at this. I was thinking it might be nice to be able to push the decision on whether to send the IPI in to the governor/hook client. For example in the schedutil case, you don't need to IPI if sugov_should_update_freq() = false (outside the slight chance it might be true when it runs on the target). Beyond that perhaps for policy reasons it's desired to not send the IPI if next_freq <= cur_freq, etc. >> 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. I was hoping to submit at some point a patch to change the context for slow path frequency changes to RT or DL context, so this would benefit that case as well. thanks, steve