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=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,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 09BF4C2B9F4 for ; Fri, 25 Jun 2021 10:21:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E50E261434 for ; Fri, 25 Jun 2021 10:21:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231430AbhFYKXk (ORCPT ); Fri, 25 Jun 2021 06:23:40 -0400 Received: from foss.arm.com ([217.140.110.172]:52272 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230082AbhFYKXh (ORCPT ); Fri, 25 Jun 2021 06:23:37 -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 CBCD4ED1; Fri, 25 Jun 2021 03:21:15 -0700 (PDT) Received: from localhost (unknown [10.1.195.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6C0933F719; Fri, 25 Jun 2021 03:21:15 -0700 (PDT) Date: Fri, 25 Jun 2021 11:21:14 +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: <20210625102113.GB15540@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Qian, On Thursday 24 Jun 2021 at 11:17:55 (-0400), Qian Cai wrote: > > > On 6/24/2021 6:48 AM, Ionela Voinescu wrote: > > Not if the counters are implemented properly. The kernel considers that > > both reference and delivered performance counters should stop or reset > > during idle. The kernel would not account for idle itself. > > > > If the reference performance counter does not stop during idle, while > > the core performance counter (delivered) does stop, the behavior above > > should be seen very often. > > > > Qian, do you see these small delivered performance values often or > > seldom? > > Ionela, so I managed to upgrade the kernel on the system to today's > linux-next which suppose to include this series. The delivered perf > is now 280. However, scaling_min_freq (200 MHz) is not equal to > lowest_perf (100). > > scaling_driver: acpi_cppc ^^^^^^^^^ I suppose you mean "cppc-cpufreq"? "acpi_cppc" is not a scaling driver option. > scaling_governor: schedutil > > Is that normal because lowest_nonlinear_perf is 200? > Yes, that is right : [1] > Also, on this pretty idle system, 158 of 160 CPUs are always running > in max freq (280 MHz). The other 2 are running in 243 and 213 MHz > according to scaling_cur_freq. Apparently, "schedutil" does not work > proper on this system. I am going to try other governors to narrow > down the issue a bit. So your CPUs run at frequencies between 200MHz and 280MHz? 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. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpufreq/cppc_cpufreq.c?h=v5.13-rc7#n296 [2] https://www.kernel.org/doc/Documentation/cpu-freq/user-guide.txt Thanks, Ionela. > > FYI, here is the acpi_cppc registers reading: > > /sys/devices/system/cpu/cpu0/acpi_cppc/feedback_ctrs > ref:160705801 del:449594095 > /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf > 300 > /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_freq > 1000 > /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_nonlinear_perf > 200 > /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_perf > 100 > /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq > 2800 > /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_perf > 280 > /sys/devices/system/cpu/cpu0/acpi_cppc/reference_perf > 100 > /sys/devices/system/cpu/cpu0/acpi_cppc/wraparound_time > 18446744073709551615