From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E914CC433E0 for ; Wed, 1 Jul 2020 14:09:05 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B3B852068F for ; Wed, 1 Jul 2020 14:09:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ya/NhMgL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B3B852068F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7Xy31Ut/j91bGjVbfNg+kZWSUBN8jbkspP7VOIU35xs=; b=ya/NhMgL2c5pU79mDbkQ9a+Y4 ngP+EXyxMOOAes5XYhpKWPnziTnNbE7xVxs+HOrUWE7TWUhzCKw7gpILo8d5G8ImDUSaP/p9ALAJi spes/qHvWqf7WiGwOeq2ulBXkGbaTBD/6asHaUgmzNiSQD58r3Tnwe0Sadp48t+04uEK2D53WTw1v iaZH2ncvmaARS9p/jyrA07QnBqx3ifSmQLBd54t+zLVZzIP9+I5TJxTMOjxbPotuZgOPrJnI76BEc 0d+6dWV2T6OV/VJJjan7psG9CpbzlWUQYJM4DcQEBtzX6CibqsRFGAUc7wEKOheTzIW4Gs7x24MVi EWLZjzttw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqdOo-0006VF-5x; Wed, 01 Jul 2020 14:07:42 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqdOk-0006To-HH for linux-arm-kernel@lists.infradead.org; Wed, 01 Jul 2020 14:07:39 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 30C0F30E; Wed, 1 Jul 2020 07:07:37 -0700 (PDT) Received: from localhost (unknown [10.1.198.53]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C614C3F73C; Wed, 1 Jul 2020 07:07:36 -0700 (PDT) Date: Wed, 1 Jul 2020 15:07:35 +0100 From: Ionela Voinescu To: Viresh Kumar Subject: Re: [PATCH 4/8] cpufreq,vexpress-spc: fix Frequency Invariance (FI) for bL switching Message-ID: <20200701140735.GB32736@arm.com> References: <20200701090751.7543-1-ionela.voinescu@arm.com> <20200701090751.7543-5-ionela.voinescu@arm.com> <20200701095414.2wjcnyhndgcedk2q@vireshk-i7> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200701095414.2wjcnyhndgcedk2q@vireshk-i7> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200701_100738_688857_ACBB2EA6 X-CRM114-Status: GOOD ( 28.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, peterz@infradead.org, catalin.marinas@arm.com, rjw@rjwysocki.net, linux@armlinux.org.uk, dietmar.eggemann@arm.com, mingo@redhat.com, sudeep.holla@arm.com, Liviu Dudau , will@kernel.org, valentin.schneider@arm.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wednesday 01 Jul 2020 at 16:16:19 (+0530), Viresh Kumar wrote: > On 01-07-20, 10:07, Ionela Voinescu wrote: > > In the majority of cases, the index argument to cpufreq's target_index() > > is meant to identify the frequency that is requested from the hardware, > > according to the frequency table: policy->freq_table[index].frequency. > > > > After successfully requesting it from the hardware, this value, together > > with the maximum hardware frequency (policy->cpuinfo.max_freq) are used > > as arguments to arch_set_freq_scale(), in order to set the task scheduler > > frequency scale factor. This is a normalized indication of a CPU's > > current performance. > > > > But for the vexpress-spc-cpufreq driver, when big.LITTLE switching [1] > > is enabled, there are three issues with using the above information for > > setting the FI scale factor: > > > > - cur_freq: policy->freq_table[index].frequency is not the frequency > > requested from the hardware. ve_spc_cpufreq_set_rate() will convert > > from this virtual frequency to an actual frequency, which is then > > requested from the hardware. For the A7 cluster, the virtual frequency > > is half the actual frequency. The use of the virtual policy->freq_table > > frequency results in an incorrect FI scale factor. > > > > - max_freq: policy->cpuinfo.max_freq does not correctly identify the > > maximum frequency of the physical cluster. This value identifies the > > maximum frequency achievable by the big-LITTLE pair, that is the > > maximum frequency of the big CPU. But when the LITTLE CPU in the group > > is used, the hardware maximum frquency passed to arch_set_freq_scale() > > is incorrect. > > > > - missing a scale factor update: when switching clusters, the driver > > recalculates the frequency of the old clock domain based on the > > requests of the remaining CPUs in the domain and asks for a clock > > change. But this does not result in an update in the scale factor. > > > > Therefore, introduce a local function bLs_set_sched_freq_scale() that > > helps call arch_set_freq_scale() with correct information for the > > is_bL_switching_enabled() case, while maintaining the old, more > > efficient, call site of arch_set_freq_scale() for when cluster > > switching is disabled. > > > > Also, because of these requirements in computing the scale factor, this > > driver is the only one that maintains custom support for FI, which is > > marked by the presence of the CPUFREQ_CUSTOM_SET_FREQ_SCALE flag. > > > > [1] https://lwn.net/Articles/481055/ > > > > Signed-off-by: Ionela Voinescu > > Cc: Viresh Kumar > > Cc: Sudeep Holla > > Cc: Rafael J. Wysocki > > Cc: Liviu Dudau > > --- > > drivers/cpufreq/vexpress-spc-cpufreq.c | 23 ++++++++++++++++++++++- > > 1 file changed, 22 insertions(+), 1 deletion(-) > > Is there anyone who cares for this driver and EAS ? I will just skip doing the > FIE thing here and mark it skipped. > That is a good question. The vexpress driver is still used for TC2, but I don't know of any users of this bL switcher functionality that's part of the driver. I think there were a few people wondering recently if it's still used [1]. If we disconsider the bL switcher functionality, then the vexpress driver itself gets in line with the other drivers supported by this series. Therefore there would not be a flag set needed here. Also, to maintain current functionality, we would not need to introduce a flag at all. But, the frequency invariance fix is also useful for schedutil to better select a frequency based on invariant utilization. So if we independently decide having a flag like the one introduced at 1/8 is useful, I would recommend to consider this patch, as it does fix some current functionality in the kernel (whether we can determine if it's used much or not). Therefore, IMO, if it's not used any more it should be removed, but if it's kept it should be fixed. [1] https://lore.kernel.org/linux-arm-kernel/20200624195811.435857-8-maz@kernel.org/ Thanks, Ionela. > -- > viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel