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.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 BAFDAC48BC2 for ; Fri, 25 Jun 2021 14:37:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A2EEE61963 for ; Fri, 25 Jun 2021 14:37:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231983AbhFYOkF (ORCPT ); Fri, 25 Jun 2021 10:40:05 -0400 Received: from foss.arm.com ([217.140.110.172]:57492 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232000AbhFYOjg (ORCPT ); Fri, 25 Jun 2021 10:39:36 -0400 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 5E6D61042; Fri, 25 Jun 2021 07:37:15 -0700 (PDT) Received: from localhost (e108754-lin.cambridge.arm.com [10.1.195.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F26903F694; Fri, 25 Jun 2021 07:37:14 -0700 (PDT) Date: Fri, 25 Jun 2021 15:37:13 +0100 From: Ionela Voinescu To: Qian Cai Cc: Vincent Guittot , Viresh Kumar , Rafael Wysocki , Ben Segall , Daniel Bristot de Oliveira , Dietmar Eggemann , Greg Kroah-Hartman , Ingo Molnar , Juri Lelli , Mel Gorman , Peter Zijlstra , "Rafael J. Wysocki" , Steven Rostedt , Sudeep Holla , Will Deacon , "open list:THERMAL" , ACPI Devel Maling List , linux-kernel , "Paul E. McKenney" , "Rafael J. Wysocki" Subject: Re: [PATCH V3 0/4] cpufreq: cppc: Add support for frequency invariance Message-ID: <20210625143713.GA7092@arm.com> References: <09a39f5c-b47b-a931-bf23-dc43229fb2dd@quicinc.com> <20210623041613.v2lo3nidpgw37abl@vireshk-i7> <2c540a58-4fef-5a3d-85b4-8862721b6c4f@quicinc.com> <20210624025414.4iszkovggk6lg6hj@vireshk-i7> <20210624104734.GA11487@arm.com> <20210625102113.GB15540@arm.com> <1f83d787-a796-0db3-3c2f-1ca616eb1979@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f83d787-a796-0db3-3c2f-1ca616eb1979@quicinc.com> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey, On Friday 25 Jun 2021 at 09:31:58 (-0400), Qian Cai wrote: > > > On 6/25/2021 6:21 AM, Ionela Voinescu wrote: > >> scaling_driver: acpi_cppc > > ^^^^^^^^^ > > I suppose you mean "cppc-cpufreq"? > > > > "acpi_cppc" is not a scaling driver option. > > Ionela, yes. Sorry about that. > > > So your CPUs run at frequencies between 200MHz and 280MHz? > > 2000 to 2800 MHz. > Thank you for the clarification. > > Based on your acpi_cppc information below I would have assumed 2GHz as > > lowest nonlinear and 2.8GHz as nominal. The reason for this is that > > according to the ACPI spec the frequency values in the _CPC objects are > > supposed to be in MHz, so 2800 MHz for nominal frequency would be > > 2.8GHz. > > > > When you try more governors, make sure to check out the difference > > between scaling_cur_freq and cpuinfo_cur_freq at [2]. The first gives > > you the frequency that the governor (schedutil) is asking for, while the > > second is giving you the current frequency obtained from the counters. > > > > So to check the actual frequency the cores are running at, please check > > cpuinfo_cur_freq. > > The problem is that all CPUs are never scaling down. "cpuinfo_cur_freq" > and "scaling_cur_freq" are always the 2800 MHz on all CPUs on this idle > system. This looks like a regression somewhere as in 5.4-based kernel, > I can see "cpuinfo_cur_freq" can go down to 2000 MHz in the same > scenario. I'll bisect a bit unless you have better ideas? Quick questions for you: 1. When you say you tried a 5.4 kernel, did you try it with these patches backported? They also have some dependencies with the recent changes in the arch topology driver and cpufreq so they would not be straight forward to backport. If the 5.4 kernel you tried did not have these patches, it might be best to try next/master that has these patches, but with CONFIG_ACPI_CPPC_CPUFREQ_FIE=n, just to eliminate the possibility that an incorrect frequency scale factor here would affect utilization that would then affect the schedutil frequency selection. I would not expect this behavior even if the scale factor was wrong, but it would be good to rule out. 2. Is your platform booting with all CPUs? Are any hotplug operations done in your scenario? Thanks, Ionela.