Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753273AbdGJJmP (ORCPT ); Mon, 10 Jul 2017 05:42:15 -0400 Received: from mail-pg0-f54.google.com ([74.125.83.54]:35249 "EHLO mail-pg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752387AbdGJJmN (ORCPT ); Mon, 10 Jul 2017 05:42:13 -0400 Date: Mon, 10 Jul 2017 15:12:09 +0530 From: Viresh Kumar To: Peter Zijlstra Cc: "Rafael J. Wysocki" , Dietmar Eggemann , "Rafael J. Wysocki" , Linux Kernel Mailing List , Linux PM , Russell King - ARM Linux , Greg Kroah-Hartman , Russell King , Catalin Marinas , Will Deacon , Juri Lelli , Vincent Guittot , Morten Rasmussen Subject: Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support Message-ID: <20170710094209.GJ2928@vireshk-i7> References: <20170706094948.8779-1-dietmar.eggemann@arm.com> <22f004af-0158-8265-2da5-34743f294bfb@arm.com> <12829054.TWIodSo4bb@aspire.rjw.lan> <20170710093051.axnd7drdnsxgiu6f@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170710093051.axnd7drdnsxgiu6f@hirez.programming.kicks-ass.net> 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: 1598 Lines: 39 On 10-07-17, 11:30, Peter Zijlstra wrote: > On Sat, Jul 08, 2017 at 02:09:37PM +0200, Rafael J. Wysocki wrote: > > Anyway, if everyone agrees that doing it in the core is the way to go (Peter?), > > why don't you introduce a __weak function for setting policy->cur and > > override it from your arch so as to call arch_set_freq_scale() from there? > > > > So I'm terminally backlogged and my recent break didn't help any with > that. > > I'm at a total loss as to what is proposed here and why we need it. I > tried reading both the Changelog and patch but came up empty. Dietmar is proposing the implementation of arch_set_freq_scale() for ARM (32/64) platforms here with following equation in drivers/base/arch_topology.c: scale = (cur_freq << SCHED_CAPACITY_SHIFT) / max_freq The only variable part here is "cur_freq" and he is looking for sane ways to get that value in the arch_topology.c file, so he can use that in the above equation. He tried to use cpufreq transition notifiers earlier but they block us from using fast switching. What he is proposing now is a function: void arch_set_freq_scale(struct cpumask *cpus, unsigned long cur_freq, unsigned long max_freq); which has to be called by someone after the frequency of the CPU is changed. Dietmar proposed that this be called by cpufreq core and Rafael was wondering if the cpufreq drivers should call it. Dietmar's argument is that it will be used for the entire ARM architecture this way and wouldn't lead to redundant core across drivers. Hope I didn't confuse you more with this :) -- viresh