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, URIBL_BLOCKED,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 AA183C49EA5 for ; Thu, 24 Jun 2021 11:23:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8ADE66124C for ; Thu, 24 Jun 2021 11:23:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232468AbhFXLZy (ORCPT ); Thu, 24 Jun 2021 07:25:54 -0400 Received: from foss.arm.com ([217.140.110.172]:54470 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232394AbhFXLZx (ORCPT ); Thu, 24 Jun 2021 07:25:53 -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 B47F21063; Thu, 24 Jun 2021 04:23:33 -0700 (PDT) Received: from localhost (unknown [10.1.195.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 542573F718; Thu, 24 Jun 2021 04:23:33 -0700 (PDT) Date: Thu, 24 Jun 2021 12:23:31 +0100 From: Ionela Voinescu To: Vincent Guittot Cc: Viresh Kumar , Qian Cai , 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: <20210624112331.GA22416@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 On Thursday 24 Jun 2021 at 13:15:04 (+0200), Vincent Guittot wrote: > On Thu, 24 Jun 2021 at 12:48, Ionela Voinescu wrote: > > > > Hi guys, > > > > On Thursday 24 Jun 2021 at 11:49:53 (+0200), Vincent Guittot wrote: > > > On Thu, 24 Jun 2021 at 04:54, Viresh Kumar wrote: > > > > > > > > On 23-06-21, 08:57, Qian Cai wrote: > > > > > Viresh, I am afraid I don't feel comfortable yet. I have a few new tests in > > > > > development, and will provide an update once ready. > > > > > > > > Oh sure, np. > > > > > > > > > Also, I noticed the delivered perf is even smaller than lowest_perf (100). > > > > > > > > > # cat /sys/devices/system/cpu/cpu8/acpi_cppc/feedback_ctrs > > > > > ref:103377547901 del:54540736873 > > > > > # cat /sys/devices/system/cpu/cpu8/acpi_cppc/feedback_ctrs > > > > > ref:103379170101 del:54541599117 > > > > > > > > > > 100 * (54541599117 - 54540736873) / (103379170101 - 103377547901) = 53 > > > > > > I'm not sure that I understand your point. The formula above says that > > > cpu8 run @ 53% of nominal performance > > > > > > > I think this is based on a previous example Qian had where: > > > > /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_perf > > 100 > > /sys/devices/system/cpu/cpu0/acpi_cppc/reference_perf > > 100 > > > > ..so the 100 is not from obtaining percentage, is the reference > > performance. > > > > The logic of the formula is to obtain the delivered performance when > > knowing the number of ticks for each counter, so: > > > > So if one gets (103379170101 - 103377547901) ticks for the counter at > > running at 1GHz(perf 100), what is the frequency of the core, if its > > counter ticked (54541599117 - 54540736873) times in the same interval > > of time? > > > > The answer is 530MHz(perf 53), which is lower than the lowest frequency > > at 1GHz(perf 100). > > But the nominal_perf is 280 and not 100 if i'm not wrong so the perf > value is 148 > lowest_perf in this case > Nominal performance has no meaning here. The reference counter ticks with the frequency equivalent to reference performance. Nominal performance is the maximum performance when !boost. Highest performance is the maximum performance available including boost frequencies. So nominal performance has no impact in these translations from counter values to delivered performance. Hope it helps, Ionela. > > > > > > > > > > > > > > > My understanding is that the delivered perf should fail into the range between > > > > > lowest_perf and highest_perf. Is that assumption correct? This happens on > > > > > 5.4-based kernel, so I am in process running your series on that system to see > > > > > if there is any differences. In any case, if it is a bug it is pre-existing, > > > > > but I'd like to understand a bit better in that front first. > > > > > > > > Vincent: > > > > > > > > Can that happen because of CPU idle ? > > > > > > > > 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? > > > > Thanks, > > Ionela. > > > > > > -- > > > > viresh