Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp3722745rdg; Wed, 18 Oct 2023 04:21:26 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFrB5yHT9HcQc7BEZnoUEd0SuulSjwhKc6/zErPyyXgMjjBauNIkn6AEQkPzzCi7rmQU2SL X-Received: by 2002:a05:6a20:4288:b0:161:346a:e7a1 with SMTP id o8-20020a056a20428800b00161346ae7a1mr6610246pzj.5.1697628086304; Wed, 18 Oct 2023 04:21:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697628086; cv=none; d=google.com; s=arc-20160816; b=hIXF6eL9sHrDg0iKxRpj31IbQ8U7suXmjgNpZ/UC+7kZJiOb6tYs7V/dojZjmdSByH Y41/eUAdfrSjHi/f981w2/1gsWafyshJapRkEF8wp8j8CnDPHiCFXTxtBNs6wxGmRyJe +vCLcBiR5LBjNTrTje/stxElHfYN3ymx1jfJjKZWJq+QopFmksX8wslzlFPkKhwS/kCk PaF3HeD6kx2R8hp9dLQIgDhXqwzrr/7BrMyb6BOCktEoLsOevGr3mg7zKn0sa9yBB5WL TQAtEvZ3IziYJqY3cRD8U//Cf9IfnpDKqmLg8nxVVQ1RZ+AcWiZKEpme4ew3sI2pA0ua z+BA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=I88wyHKWOQ6YVtQViWtEnIig8BNgQrYEB996rGBfB1g=; fh=ea04K7+ScIyGsWA0Wg4WRzVAn3SyUnkwgPw59UOkhRc=; b=LH8iFOJQKGt/safZPatHA+sokka05Cu/84Fam6UJ8yUUD5zbpJ/Spw6UNdbNEru6lM tcWn74cKJH4JpfiMjQyduJbX572nss6IEaHlqluS4HcJ/M/9ig7kJ7nuUcivDxoNjLVN IKqR+6EaiIdwgSTBGPxG53eG/iECUXCfhKAFtFVuXRnyN4wv9FBUSVIIqi8tLnGXUCJQ 2eZuBTeV1lSxYv5cz7oIekfGDDX6AF9M92//FIAnWeCB5Jw7KVzFCNGq4ieVYtU4TklK SJNfBWJAsx9uj2gug1vEwy5raCnUtA/XxlEcwVmphVq7zlSIKcqhl9jNaBZUL5dx3mGX EDfA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 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 pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id f9-20020a639c09000000b005a9abc4b6a9si1797228pge.281.2023.10.18.04.21.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Oct 2023 04:21:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 765E78029217; Wed, 18 Oct 2023 04:21:23 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229702AbjJRLVM (ORCPT + 99 others); Wed, 18 Oct 2023 07:21:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53404 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230250AbjJRLVK (ORCPT ); Wed, 18 Oct 2023 07:21:10 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CA1FA115; Wed, 18 Oct 2023 04:21:08 -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 283602F4; Wed, 18 Oct 2023 04:21:49 -0700 (PDT) Received: from [10.57.81.189] (unknown [10.57.81.189]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9534E3F762; Wed, 18 Oct 2023 04:21:03 -0700 (PDT) Message-ID: <368c8a9f-b137-47a9-9468-ebeb04d4bab5@arm.com> Date: Wed, 18 Oct 2023 12:21:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/6] cpufreq/schedutil: use a fixed reference frequency Content-Language: en-US To: Vincent Guittot Cc: conor.dooley@microchip.com, suagrfillet@gmail.com, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, vschneid@redhat.com, bsegall@google.com, dietmar.eggemann@arm.com, juri.lelli@redhat.com, peterz@infradead.org, rafael@kernel.org, gregkh@linuxfoundation.org, ajones@ventanamicro.com, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, sudeep.holla@arm.com, ionela.voinescu@arm.com, viresh.kumar@linaro.org, mgorman@suse.de, palmer@dabbelt.com, will@kernel.org, bristot@redhat.com, lftan@kernel.org, rostedt@goodmis.org, linux@armlinux.org.uk, paul.walmsley@sifive.com, aou@eecs.berkeley.edu, mingo@redhat.com, catalin.marinas@arm.com, pierre.gondois@arm.com References: <20231009103621.374412-1-vincent.guittot@linaro.org> <20231009103621.374412-5-vincent.guittot@linaro.org> From: Lukasz Luba In-Reply-To: <20231009103621.374412-5-vincent.guittot@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Wed, 18 Oct 2023 04:21:23 -0700 (PDT) On 10/9/23 11:36, Vincent Guittot wrote: > cpuinfo.max_freq can change at runtime because of boost as an example. This > implies that the value could be different than the one that has been > used when computing the capacity of a CPU. > > The new arch_scale_freq_ref() returns a fixed and coherent reference > frequency that can be used when computing a frequency based on utilization. > > Use this arch_scale_freq_ref() when available and fallback to > policy otherwise. > > Signed-off-by: Vincent Guittot > --- > kernel/sched/cpufreq_schedutil.c | 26 ++++++++++++++++++++++++-- > 1 file changed, 24 insertions(+), 2 deletions(-) > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > index 4492608b7d7f..1fa7e74add8f 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -114,6 +114,28 @@ static void sugov_deferred_update(struct sugov_policy *sg_policy) > } > } > > +/** > + * cpufreq_get_capacity_ref_freq - get the reference frequency of a given CPU that > + * has been used to correlate frequency and compute capacity. > + * @policy: the cpufreq policy of the CPU in question. > + * @use_current: Fallback to current freq instead of policy->cpuinfo.max_freq. > + * > + * Return: the reference CPU frequency to compute a capacity. > + */ > +static __always_inline > +unsigned long get_capacity_ref_freq(struct cpufreq_policy *policy) > +{ > + unsigned int freq = arch_scale_freq_ref(policy->cpu); > + > + if (freq) > + return freq; Looks good, for the platforms having this inline function returning 0, this will be optimized out. > + > + if (arch_scale_freq_invariant()) > + return policy->cpuinfo.max_freq; > + > + return policy->cur; > +} > + > /** > * get_next_freq - Compute a new frequency for a given cpufreq policy. > * @sg_policy: schedutil policy object to compute the new frequency for. > @@ -140,10 +162,10 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy, > unsigned long util, unsigned long max) > { > struct cpufreq_policy *policy = sg_policy->policy; > - unsigned int freq = arch_scale_freq_invariant() ? > - policy->cpuinfo.max_freq : policy->cur; > + unsigned int freq; > > util = map_util_perf(util); > + freq = get_capacity_ref_freq(policy); > freq = map_util_freq(util, freq, max); > > if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update) Reviewed-by: Lukasz Luba