Message ID | 2258064.ElGaqSPkdT@kreacher |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp688586wru; Mon, 24 Oct 2022 15:50:57 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5sHI6dV6IPFUS45KQcuG89GKaNVE141KX9QkwLs4X0otnY6MP2DY8a+GCwy7RABBSlr5Gl X-Received: by 2002:a63:1d5a:0:b0:46e:d157:39ef with SMTP id d26-20020a631d5a000000b0046ed15739efmr13913552pgm.231.1666651857455; Mon, 24 Oct 2022 15:50:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666651857; cv=none; d=google.com; s=arc-20160816; b=u5ZIk1GHoo9rxjvSMzNpvfd06tfN9tHx6+SvAYBHfIupqBe72NWEphDFQm67he5cNT 1pQCpjPqUj8s86Z3MJd4C7s/rN/MSKnLqmVQMqZ4lVROwN/IQu1/7zuFgkwYzFdviGw1 ZxVMzkamZ1jsQrsjE+QrZop5q0Pt4ye9UHVofVP4I7SLmHn144NfYZe0AuGHuNIbnNoM 00rlU0b9ez1I6o6SZfZbdJeAMYmV7JEt3mgCYMhas8+BJEYAWpDTMIX1C20fRp63T/jm WK7IB61gQjePVjWOFPtB/Tuz8xuvGHGLDsCHpPfKvR13I40g8lBX0pTydq8Yf5voLMMd ZBEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=flC9Z2A82xtLHGYSaVs0SsYumG1SulHaB9mVMUKbQog=; b=irabXVmhGdXgX0vrNB8REVI6s/wWBtcx+LaX+P2P8T2bV5VPVsavK5Ez0zvc0JqQV4 8bBpSN3HE4UPlsTtwnJWyrmWBSS3oWiEJHuZU0ekGfSNkVI9ZMoGAdfPJ0TjZ6eDNIpH 8uOQOWrAPuRZCegdC/DcAFaen3XkVoqMmz84iov0UEXjT7uN5Grbbg/VqpsMaEF4vIu+ Rud7bSDYihWua456QB94mgDS0dsJCr3eTt9MAtJvAbvaLRIGxQwvmBbWZP2WshqZsAyc LmukblDAFEulAPauS9ZgrKR7DImO9XatJxu/DH/wyeHf/w41Uv2YTBAbf0VJngK9GdyL axtw== 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w5-20020a056a0014c500b00567719e34aesi1377374pfu.49.2022.10.24.15.50.44; Mon, 24 Oct 2022 15:50:57 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232135AbiJXWuM (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Mon, 24 Oct 2022 18:50:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231490AbiJXWtp (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 24 Oct 2022 18:49:45 -0400 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4934049B6C; Mon, 24 Oct 2022 14:11:34 -0700 (PDT) Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 5.0.0) id 696992e5b47a83ad; Mon, 24 Oct 2022 21:23:37 +0200 Received: from kreacher.localnet (unknown [213.134.163.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by v370.home.net.pl (Postfix) with ESMTPSA id BBC446692BC; Mon, 24 Oct 2022 21:23:36 +0200 (CEST) From: "Rafael J. Wysocki" <rjw@rjwysocki.net> To: Linux PM <linux-pm@vger.kernel.org> Cc: LKML <linux-kernel@vger.kernel.org>, Len Brown <len.brown@intel.com>, Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>, Linux ACPI <linux-acpi@vger.kernel.org> Subject: [PATCH 0/2] cpufreq: intel_pstate: Make HWP calibration work on all hybrid platforms Date: Mon, 24 Oct 2022 21:18:19 +0200 Message-ID: <2258064.ElGaqSPkdT@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-CLIENT-IP: 213.134.163.181 X-CLIENT-HOSTNAME: 213.134.163.181 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvfedrgedtgedgudefudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpeffffffkefgheehffelteeiveeffeevhfelteejvddvieejjeelvdeiheeuveeuffenucfkphepvddufedrudefgedrudeifedrudekudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvudefrddufeegrdduieefrddukedupdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqpdhnsggprhgtphhtthhopeehpdhrtghpthhtoheplhhinhhugidqphhmsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhgvnhdrsghrohifnhesihhnthgvlhdrtghomhdprhgtphhtthhopehsrhhinhhivhgrshdrphgrnhgurhhuvhgruggrsehlihhnuhigrdhinhhtvghlrdgt ohhmpdhrtghpthhtoheplhhinhhugidqrggtphhisehvghgvrhdrkhgvrhhnvghlrdhorhhg X-DCC--Metrics: v370.home.net.pl 1024; Body=5 Fuz1=5 Fuz2=5 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747611138346896157?= X-GMAIL-MSGID: =?utf-8?q?1747611138346896157?= |
Series |
cpufreq: intel_pstate: Make HWP calibration work on all hybrid platforms
|
|
Message
Rafael J. Wysocki
Oct. 24, 2022, 7:18 p.m. UTC
Hi All, The HWP calibration in intel_pstate is needed to map HWP performance levels to frequencies, which are used in the cpufreq sysfs interface, in a reliable way. On all non-hybrid "core" platforms it is sufficient to multiply the HWP performance levels by 100000 to obtain the corresponding frequencies, but on hybrid ones there is a difference between P-cores and E-cores. Previous attempts to make this work were based on using CPPC (and in particular the nominal performance values provided by _CPC), but it turns out that the CPPC information is not sufficiently reliable for this purpose and the only way to do it is to use a hard-coded scaling factors for P-cores and for E-cores (which fortunately is the same as in the non-hybrid case). Fortunately, the same scaling factor for P-cores works on all of the hybrid platforms to date. The first patch in the series ensures that all of the CPUs will use correct information from MSRs by avoiding the situations in which an MSR values read on one CPU will be used for performance scaling of another CPU. The second one implements the approach outlined above. Please see the changelogs for details. Thanks!
Comments
On Mon, 2022-10-24 at 21:18 +0200, Rafael J. Wysocki wrote: > Hi All, > > The HWP calibration in intel_pstate is needed to map HWP performance > levels to > frequencies, which are used in the cpufreq sysfs interface, in a > reliable way. > On all non-hybrid "core" platforms it is sufficient to multiply the > HWP > performance levels by 100000 to obtain the corresponding frequencies, > but on > hybrid ones there is a difference between P-cores and E-cores. > > Previous attempts to make this work were based on using CPPC (and in > particular > the nominal performance values provided by _CPC), but it turns out > that the > CPPC information is not sufficiently reliable for this purpose and > the only > way to do it is to use a hard-coded scaling factors for P-cores and > for E-cores > (which fortunately is the same as in the non-hybrid case). > Fortunately, the > same scaling factor for P-cores works on all of the hybrid platforms > to date. > > The first patch in the series ensures that all of the CPUs will use > correct > information from MSRs by avoiding the situations in which an MSR > values read > on one CPU will be used for performance scaling of another CPU. > > The second one implements the approach outlined above. > > Please see the changelogs for details. Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > > Thanks! > > >
On Tue, Oct 25, 2022 at 1:58 AM srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote: > > On Mon, 2022-10-24 at 21:18 +0200, Rafael J. Wysocki wrote: > > Hi All, > > > > The HWP calibration in intel_pstate is needed to map HWP performance > > levels to > > frequencies, which are used in the cpufreq sysfs interface, in a > > reliable way. > > On all non-hybrid "core" platforms it is sufficient to multiply the > > HWP > > performance levels by 100000 to obtain the corresponding frequencies, > > but on > > hybrid ones there is a difference between P-cores and E-cores. > > > > Previous attempts to make this work were based on using CPPC (and in > > particular > > the nominal performance values provided by _CPC), but it turns out > > that the > > CPPC information is not sufficiently reliable for this purpose and > > the only > > way to do it is to use a hard-coded scaling factors for P-cores and > > for E-cores > > (which fortunately is the same as in the non-hybrid case). > > Fortunately, the > > same scaling factor for P-cores works on all of the hybrid platforms > > to date. > > > > The first patch in the series ensures that all of the CPUs will use > > correct > > information from MSRs by avoiding the situations in which an MSR > > values read > > on one CPU will be used for performance scaling of another CPU. > > > > The second one implements the approach outlined above. > > > > Please see the changelogs for details. > > Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Thank you! As discussed offline, I'm going to fast-track this series as urgent fixes to cover systems in the field that are likely to have problems related to it.