Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp2545881rwa; Mon, 22 Aug 2022 09:20:14 -0700 (PDT) X-Google-Smtp-Source: AA6agR5s1GvUmeRY3XMJmfR7cM4sAXfiULRfD32FPcdDe/7jIyHmpOsABA3kWLqocaxabV1Yi8Fe X-Received: by 2002:a63:5903:0:b0:41a:767:7adc with SMTP id n3-20020a635903000000b0041a07677adcmr17863128pgb.615.1661185214175; Mon, 22 Aug 2022 09:20:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661185214; cv=none; d=google.com; s=arc-20160816; b=JYh/+Du65v8b545H4YIXlluCE8x3/QQoIu0KSslVa01r9Nsi2CicZQhTzu1f3mfd2r p+r3P+6Exl2s4d1vHMzUNAalKZDlECp5DJ++ox951PoHOWgfOr/XvxMbJjT1V8OVg7PN i3zRw3Y+PPvn/IlxZpPwiv2E8JwV30CEnNzJECHA4jut3fSN5rARvD36a/S48WiEI1TL OFxOIvpWRlsLMJbkqainvZ5qqtFHCagQxFL4MHJUc4zjSd8g1dNP1WnOUnZG+gGAMmuE OFAP+2rLkUYM4nkQ/Bm1k3SsjbbhE+YbmdaCtNklnDvvi7hrkmWgPcm0/WUUJsIMfH8B Dg/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=re1WmHnrUpBZUbCnEeD2/c0XeSo5CTAeK290a2PtaGk=; b=zVoZUjl96K5k2cGMcuVF/+FbLBVtBg+ar7b5Tva6L8fDa8YOLnqSyCxmNJ2e8q5Cyx 1p91hHw6Z9nAfoYbr3e8N2flSH2F2PSp0M4papqX0+gRJSDk77oUxCFF9ih0ZdzK5olD VSH7wH6ADMSlh2h4eI/eo3i7vR1Kh733s6eIMlln6kLjcBJUm9bRoHK38ReU1v9icQ77 +EvYGn4XEY4kvacK5VXhfXz3SdBO5gCDRGgA/6orZNyFDajCN69O+AKjGhh7bt7KtM+F T73NSBlm8ns8plpsAXlwjSaCEj9RVw64aID+3JjoRlyNrt/rxSwjARjChmXYi9C0D4iw VcyA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g21-20020a170902e39500b0016d47244b85si11491093ple.327.2022.08.22.09.20.02; Mon, 22 Aug 2022 09:20:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236934AbiHVQBL (ORCPT + 99 others); Mon, 22 Aug 2022 12:01:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237014AbiHVQA5 (ORCPT ); Mon, 22 Aug 2022 12:00:57 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9DA8915A38; Mon, 22 Aug 2022 09:00:56 -0700 (PDT) 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 A33C7ED1; Mon, 22 Aug 2022 09:00:59 -0700 (PDT) Received: from e126311.manchester.arm.com (unknown [10.57.75.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C728C3F70D; Mon, 22 Aug 2022 09:00:54 -0700 (PDT) Date: Mon, 22 Aug 2022 16:59:46 +0100 From: Kajetan Puchalski To: Lukasz Luba Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, viresh.kumar@linaro.org, rafael@kernel.org, kajetan.puchalski@arm.com Subject: Re: [PATCH v2] cpufreq: check only freq_table in __resolve_freq() Message-ID: References: <20220816120157.24455-1-lukasz.luba@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220816120157.24455-1-lukasz.luba@arm.com> X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 16, 2022 at 01:01:57PM +0100, Lukasz Luba wrote: > There is no need to check if the cpufreq driver implements callback > cpufreq_driver::target_index. The logic in the __resolve_freq uses > the frequency table available in the policy. It doesn't matter if the > driver provides 'target_index' or 'target' callback. It just has to > populate the 'policy->freq_table'. > > Thus, check only frequency table during the frequency resolving call. > > Acked-by: Viresh Kumar > Signed-off-by: Lukasz Luba > --- > Changes: > v2: > - collected ACK from Viresh > - corrected patch description (Viresh) Just to stress how important this fix is, without this patch while running tests on a Pixel 6 cpufreq was reporting frequencies that were completely not aligned with the OPPs on the device and harming performance in the process. For instance, after applying the patch the average score in Geekbench 5 increased by over 130 (about 5%). The average score in Speedometer 2 increased by about 6 (over 6%). > drivers/cpufreq/cpufreq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 7820c4e74289..69b3d61852ac 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -532,7 +532,7 @@ static unsigned int __resolve_freq(struct cpufreq_policy *policy, > > target_freq = clamp_val(target_freq, policy->min, policy->max); > > - if (!cpufreq_driver->target_index) > + if (!policy->freq_table) > return target_freq; > > idx = cpufreq_frequency_table_target(policy, target_freq, relation); > -- > 2.17.1 >