Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp3714610rdg; Wed, 18 Oct 2023 04:06:05 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH30zgKl3laDjrpEU85V+syqfF4kAcYPkKbvBdTmfEwPLpatN3mB0reR8trsxVfpmXq40ra X-Received: by 2002:a17:903:138f:b0:1ca:18b3:3599 with SMTP id jx15-20020a170903138f00b001ca18b33599mr3892641plb.68.1697627164899; Wed, 18 Oct 2023 04:06:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697627164; cv=none; d=google.com; s=arc-20160816; b=ib3P80Hn5reDnT2JRokmFKyvbKUO0dvWvCxLGBMNBtahs0CP9ezrV3uYrMN1aziGhJ Rb+POlZZ2WDOGPiGAcEYvOV8eLggLQchLxCnn5dgNm1x6pBPypWEbGY+Vfy81vfY21Vk SaK6sC3MiBh8UtZ0siE4qIcsZGsSdR08JWO3WeiM4+526fNjLw0lPcRArg3udapbSEmN 03gboDLHy7yUVoXxOUFRgPVT8B7cxIePo6fNt92L0NrYziN32fQcO7UGfI21pBc1iMB6 oPKwr55mAFYa05OlQMr78SQ7HR2h30x+RKF5WD+ditcgRTrNBF/f8HD7hhxvKxxwVEQ5 5edg== 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=jt/pglc9lmy1zqTloAU2eEiOcJRY7BwOPbh1IvpA+Es=; fh=TblrcrOPYTsmMB7T5TpxEFHp1BUb61/xO2nb0AfXSaU=; b=wvVgRPAlLlBAYlAPvFSZtQUsFbrDT1JvPkbd6lk5f1aliOOOOHCQ+dhhTERtZbxsPt QMo4zn0PlaUGZayVRWiE3qYREXNvsHGTSiDLBn15UacIPuTrtKqQRJIS9LKmk/SomM60 XLMT3Ve6U/gqto88e+zxlbSfgIyirTg6+B8d3qt0EF8DamtK6JmYoVaWxqSu1nN3daDd 7Q0DvlC+GkuHcLzxNk+pIWlpUgyazPFUiCHye4vS3DM70XqA7Ezrz6FxAHfPfzBdDoEm EA1AiBBWB45NluP/ndg0i0ZGW5s+IT8ZwsN06q2eawi3KXDQ4Bf46iJVnoxsQhEW+24B X/Fg== 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:3 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 lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id b15-20020a170902650f00b001c60e273252si3724570plk.25.2023.10.18.04.06.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Oct 2023 04:06:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 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 lipwig.vger.email (Postfix) with ESMTP id 94205805A793; Wed, 18 Oct 2023 04:05:52 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230023AbjJRLFo (ORCPT + 99 others); Wed, 18 Oct 2023 07:05:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229690AbjJRLFm (ORCPT ); Wed, 18 Oct 2023 07:05:42 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9120C111; Wed, 18 Oct 2023 04:05:40 -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 36F462F4; Wed, 18 Oct 2023 04:06:21 -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 AA1F93F762; Wed, 18 Oct 2023 04:05:35 -0700 (PDT) Message-ID: Date: Wed, 18 Oct 2023 12:06:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/6] topology: add a new arch_scale_freq_reference Content-Language: en-US To: Vincent Guittot Cc: conor.dooley@microchip.com, will@kernel.org, ionela.voinescu@arm.com, vschneid@redhat.com, mgorman@suse.de, bsegall@google.com, dietmar.eggemann@arm.com, peterz@infradead.org, sudeep.holla@arm.com, aou@eecs.berkeley.edu, palmer@dabbelt.com, linux-pm@vger.kernel.org, linux-riscv@lists.infradead.org, pierre.gondois@arm.com, paul.walmsley@sifive.com, catalin.marinas@arm.com, linux@armlinux.org.uk, suagrfillet@gmail.com, ajones@ventanamicro.com, juri.lelli@redhat.com, lftan@kernel.org, mingo@redhat.com, rafael@kernel.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, bristot@redhat.com, viresh.kumar@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20231009103621.374412-1-vincent.guittot@linaro.org> <20231009103621.374412-3-vincent.guittot@linaro.org> From: Lukasz Luba In-Reply-To: <20231009103621.374412-3-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 lipwig.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 (lipwig.vger.email [0.0.0.0]); Wed, 18 Oct 2023 04:05:52 -0700 (PDT) On 10/9/23 11:36, Vincent Guittot wrote: > Create a new method to get a unique and fixed max frequency. Currently > cpuinfo.max_freq or the highest (or last) state of performance domain are > used as the max frequency when computing the frequency for a level of > utilization but: > - cpuinfo_max_freq can change at runtime. boost is one example of > such change. > - cpuinfo.max_freq and last item of the PD can be different leading to > different results between cpufreq and energy model. > > We need to save the reference frequency that has been used when computing > the CPUs capacity and use this fixed and coherent value to convert between > frequency and CPU's capacity. > > In fact, we already save the frequency that has been used when computing > the capacity of each CPU. We extend the precision to save khZ instead of > Mhz currently and we modify the type to be aligned with other variables > used when converting frequency to capacity and the other way. > > Signed-off-by: Vincent Guittot > --- > arch/arm/include/asm/topology.h | 1 + > arch/arm64/include/asm/topology.h | 1 + > arch/riscv/include/asm/topology.h | 1 + > drivers/base/arch_topology.c | 29 ++++++++++++++--------------- > include/linux/arch_topology.h | 7 +++++++ > 5 files changed, 24 insertions(+), 15 deletions(-) [snip] > @@ -170,9 +172,9 @@ DEFINE_PER_CPU(unsigned long, thermal_pressure); > * operating on stale data when hot-plug is used for some CPUs. The > * @capped_freq reflects the currently allowed max CPUs frequency due to > * thermal capping. It might be also a boost frequency value, which is bigger > - * than the internal 'freq_factor' max frequency. In such case the pressure > - * value should simply be removed, since this is an indication that there is > - * no thermal throttling. The @capped_freq must be provided in kHz. > + * than the internal 'capacity_ref_freq' max frequency. In such case the > + * pressure value should simply be removed, since this is an indication that > + * there is no thermal throttling. The @capped_freq must be provided in kHz. > */ > void topology_update_thermal_pressure(const struct cpumask *cpus, > unsigned long capped_freq) > @@ -183,10 +185,7 @@ void topology_update_thermal_pressure(const struct cpumask *cpus, > > cpu = cpumask_first(cpus); > max_capacity = arch_scale_cpu_capacity(cpu); > - max_freq = per_cpu(freq_factor, cpu); > - > - /* Convert to MHz scale which is used in 'freq_factor' */ > - capped_freq /= 1000; I do like this small speed-up and I'm happy that it's possible with this new design. (IIRC some of your platforms can update the thermal pressure quite many time per sec - that might be the reason why you see some speed-ups mentioned in the cover letter) > + max_freq = arch_scale_freq_ref(cpu); > LGTM Reviewed-by: Lukasz Luba