Message ID | 12124970.O9o76ZdvQC@kreacher |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp2094996wrt; Wed, 28 Dec 2022 13:30:57 -0800 (PST) X-Google-Smtp-Source: AMrXdXt6SDhFXyP7g8Sga7KhI9tPWTpXCbiDPhMhFxS2KKHqzUjtjb4X7/2cbtzRyUVqJgWRZBzW X-Received: by 2002:a05:6a21:6d9c:b0:b1:dac3:37b9 with SMTP id wl28-20020a056a216d9c00b000b1dac337b9mr41554833pzb.45.1672263056916; Wed, 28 Dec 2022 13:30:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672263056; cv=none; d=google.com; s=arc-20160816; b=P3dhj2hiO50rpUQYRfwNQsAxjbolwJeNv4FCvHaNaVfHxbCGmsOvwv3jWlcDCKX0c1 35OEc7cdbW+Lb/H13Bf4MjYLbambItlTXL454/s+miibJGpRgFpC7Vcm/DaUK57lrcVT YEruB6tW6gyRpuIhzP4fBsj7gkyN9eMwhBLIVmLoeISPDoBD48itb2G3BGauqjRrE6TR F7D29Eqh/p0cpEtZCRYqojGdE7UOnB7Ufyn69pNYMq1nkDZaarsGr5YbmmGit8n+rukP oqRiIwbxGsTFDOLjXHrUFZD6nxpEOm8uRsussyq2KeNP5HVQ7euPuZdzVmOLK6DRbZlf vlBA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=ff6wVwE540HivirRVQLgVU/671lCveAUHY/zJZxw9ro=; b=SuKBK4XNlLhjB+hXKWO8RuuVquHONxuLOqhQ/WP2Oax/eZrDlw+dFLMyE0a+agTnKH qZZo3hAVZRmTKkiD0tofgKxOucXwa9NzyWXFXgiL5GCYr+DGqPsbNqgv3rh34wsNOPe2 4NgEzd2VWsnP5ktWx/XSelP9CWUEmKIqPsjpSKTlL3uJWkp2zhLd4aLn8HmywFCj6EuC 4W3ZfnJsxXDsMn0n8ZdnuVZOqfuqzSMmwzKUUFsghtN5j+2XMY+ufzr3uLNivJfCIHZL 9Rgi04fab7/u4WH+HzUeZD2V0dlT1gMk8+IE83erggx91GTe67s+MU6rBmpZ46G7avUY uXfg== 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 c14-20020a63ea0e000000b00476b6fa2963si17676876pgi.599.2022.12.28.13.30.44; Wed, 28 Dec 2022 13:30:56 -0800 (PST) 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 S232110AbiL1V1d (ORCPT <rfc822;eddaouddi.ayoub@gmail.com> + 99 others); Wed, 28 Dec 2022 16:27:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231338AbiL1V1W (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 28 Dec 2022 16:27:22 -0500 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 544C4140AF; Wed, 28 Dec 2022 13:27:21 -0800 (PST) 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.1.0) id 36817dc0ed6b8a83; Wed, 28 Dec 2022 22:27:19 +0100 Received: from kreacher.localnet (89-77-51-84.dynamic.chello.pl [89.77.51.84]) (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 12A5D780AF8; Wed, 28 Dec 2022 22:27:19 +0100 (CET) Authentication-Results: v370.home.net.pl; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: v370.home.net.pl; spf=fail smtp.mailfrom=rjwysocki.net From: "Rafael J. Wysocki" <rjw@rjwysocki.net> To: Linux PM <linux-pm@vger.kernel.org> Cc: Pratyush Yadav <ptyadav@amazon.de>, LKML <linux-kernel@vger.kernel.org>, Linux ACPI <linux-acpi@vger.kernel.org>, Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Subject: [PATCH v2 1/3] ACPI: processor: perflib: Use the "no limit" frequency QoS Date: Wed, 28 Dec 2022 22:21:49 +0100 Message-ID: <12124970.O9o76ZdvQC@kreacher> In-Reply-To: <12138067.O9o76ZdvQC@kreacher> References: <12138067.O9o76ZdvQC@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-CLIENT-IP: 89.77.51.84 X-CLIENT-HOSTNAME: 89-77-51-84.dynamic.chello.pl X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedriedvgdduhedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecujffqoffgrffnpdggtffipffknecuuegrihhlohhuthemucduhedtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqnecuggftrfgrthhtvghrnhepvdffueeitdfgvddtudegueejtdffteetgeefkeffvdeftddttdeuhfegfedvjefhnecukfhppeekledrjeejrdehuddrkeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepkeelrdejjedrhedurdekgedphhgvlhhopehkrhgvrggthhgvrhdrlhhotggrlhhnvghtpdhmrghilhhfrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqedpnhgspghrtghpthhtohephedprhgtphhtthhopehlihhnuhigqdhpmhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehpthihrggurghvsegrmhgriihonhdruggvpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqrggtphhisehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtohepshhrihhnihhvrghs rdhprghnughruhhvrggurgeslhhinhhugidrihhnthgvlhdrtghomh 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?1753398641352408968?= X-GMAIL-MSGID: =?utf-8?q?1753494906793673988?= |
Series |
[v2,1/3] ACPI: processor: perflib: Use the "no limit" frequency QoS
|
|
Commit Message
Rafael J. Wysocki
Dec. 28, 2022, 9:21 p.m. UTC
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> When _PPC returns 0, it means that the CPU frequency is not limited by the platform firmware, so make acpi_processor_get_platform_limit() update the frequency QoS request used by it to "no limit" in that case. This addresses a problem with limiting CPU frequency artificially on some systems after CPU offline/online to the frequency that corresponds to the first entry in the _PSS return package. Reported-by: Pratyush Yadav <ptyadav@amazon.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> --- v1 -> v2: * Move some changes into a separate patch * Update the changelog accordingly --- drivers/acpi/processor_perflib.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-)
Comments
Hi Rafael, On Wed, Dec 28 2022, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > When _PPC returns 0, it means that the CPU frequency is not limited by > the platform firmware, so make acpi_processor_get_platform_limit() > update the frequency QoS request used by it to "no limit" in that case. > > This addresses a problem with limiting CPU frequency artificially on > some systems after CPU offline/online to the frequency that corresponds > to the first entry in the _PSS return package. > > Reported-by: Pratyush Yadav <ptyadav@amazon.de> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > > v1 -> v2: > * Move some changes into a separate patch > * Update the changelog accordingly > > --- > drivers/acpi/processor_perflib.c | 20 ++++++++++++++++---- > 1 file changed, 16 insertions(+), 4 deletions(-) > > Index: linux-pm/drivers/acpi/processor_perflib.c > =================================================================== > --- linux-pm.orig/drivers/acpi/processor_perflib.c > +++ linux-pm/drivers/acpi/processor_perflib.c > @@ -53,6 +53,8 @@ static int acpi_processor_get_platform_l > { > acpi_status status = 0; > unsigned long long ppc = 0; > + s32 qos_value; > + int index; > int ret; > > if (!pr) > @@ -72,17 +74,27 @@ static int acpi_processor_get_platform_l > } > } > > + index = ppc; > + > pr_debug("CPU %d: _PPC is %d - frequency %s limited\n", pr->id, > - (int)ppc, ppc ? "" : "not"); > + index, index ? "is" : "is not"); > > - pr->performance_platform_limit = (int)ppc; > + pr->performance_platform_limit = index; > > if (ppc >= pr->performance->state_count || > unlikely(!freq_qos_request_active(&pr->perflib_req))) > return 0; > > - ret = freq_qos_update_request(&pr->perflib_req, > - pr->performance->states[ppc].core_frequency * 1000); > + /* > + * If _PPC returns 0, it means that all of the available states can be > + * used ("no limit"). > + */ > + if (index == 0) > + qos_value = FREQ_QOS_MAX_DEFAULT_VALUE; One small thing I noticed: in acpi_processor_ppc_init() "no limit" value is set to INT_MAX and here it is set to FREQ_QOS_MAX_DEFAULT_VALUE. Both should evaluate to the same value but I think it would be nice if the same thing is used in both places. Perhaps you can fix that up when applying? Other than this, Reviewed-by: Pratyush Yadav <ptyadav@amazon.de> Tested-by: Pratyush Yadav <ptyadav@amazon.de> Thanks for working on this. > + else > + qos_value = pr->performance->states[index].core_frequency * 1000; > + > + ret = freq_qos_update_request(&pr->perflib_req, qos_value); > if (ret < 0) { > pr_warn("Failed to update perflib freq constraint: CPU%d (%d)\n", > pr->id, ret); > > >
On Thu, Dec 29, 2022 at 1:58 PM Pratyush Yadav <ptyadav@amazon.de> wrote: > > Hi Rafael, > > On Wed, Dec 28 2022, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > When _PPC returns 0, it means that the CPU frequency is not limited by > > the platform firmware, so make acpi_processor_get_platform_limit() > > update the frequency QoS request used by it to "no limit" in that case. > > > > This addresses a problem with limiting CPU frequency artificially on > > some systems after CPU offline/online to the frequency that corresponds > > to the first entry in the _PSS return package. > > > > Reported-by: Pratyush Yadav <ptyadav@amazon.de> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > --- > > > > v1 -> v2: > > * Move some changes into a separate patch > > * Update the changelog accordingly > > > > --- > > drivers/acpi/processor_perflib.c | 20 ++++++++++++++++---- > > 1 file changed, 16 insertions(+), 4 deletions(-) > > > > Index: linux-pm/drivers/acpi/processor_perflib.c > > =================================================================== > > --- linux-pm.orig/drivers/acpi/processor_perflib.c > > +++ linux-pm/drivers/acpi/processor_perflib.c > > @@ -53,6 +53,8 @@ static int acpi_processor_get_platform_l > > { > > acpi_status status = 0; > > unsigned long long ppc = 0; > > + s32 qos_value; > > + int index; > > int ret; > > > > if (!pr) > > @@ -72,17 +74,27 @@ static int acpi_processor_get_platform_l > > } > > } > > > > + index = ppc; > > + > > pr_debug("CPU %d: _PPC is %d - frequency %s limited\n", pr->id, > > - (int)ppc, ppc ? "" : "not"); > > + index, index ? "is" : "is not"); > > > > - pr->performance_platform_limit = (int)ppc; > > + pr->performance_platform_limit = index; > > > > if (ppc >= pr->performance->state_count || > > unlikely(!freq_qos_request_active(&pr->perflib_req))) > > return 0; > > > > - ret = freq_qos_update_request(&pr->perflib_req, > > - pr->performance->states[ppc].core_frequency * 1000); > > + /* > > + * If _PPC returns 0, it means that all of the available states can be > > + * used ("no limit"). > > + */ > > + if (index == 0) > > + qos_value = FREQ_QOS_MAX_DEFAULT_VALUE; > > One small thing I noticed: in acpi_processor_ppc_init() "no limit" value > is set to INT_MAX and here it is set to FREQ_QOS_MAX_DEFAULT_VALUE. Both > should evaluate to the same value but I think it would be nice if the > same thing is used in both places. Perhaps you can fix that up when > applying? Yes, I'll do that. > Other than this, > > Reviewed-by: Pratyush Yadav <ptyadav@amazon.de> > Tested-by: Pratyush Yadav <ptyadav@amazon.de> Thanks! > Thanks for working on this. You're welcome.
Hi Rafael, On Thu, Dec 29 2022, Rafael J. Wysocki wrote: > On Thu, Dec 29, 2022 at 1:58 PM Pratyush Yadav <ptyadav@amazon.de> wrote: >> >> Hi Rafael, >> >> On Wed, Dec 28 2022, Rafael J. Wysocki wrote: >> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> > >> > When _PPC returns 0, it means that the CPU frequency is not limited by >> > the platform firmware, so make acpi_processor_get_platform_limit() >> > update the frequency QoS request used by it to "no limit" in that case. >> > >> > This addresses a problem with limiting CPU frequency artificially on >> > some systems after CPU offline/online to the frequency that corresponds >> > to the first entry in the _PSS return package. >> > >> > Reported-by: Pratyush Yadav <ptyadav@amazon.de> >> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> > --- [...] >> >> One small thing I noticed: in acpi_processor_ppc_init() "no limit" value >> is set to INT_MAX and here it is set to FREQ_QOS_MAX_DEFAULT_VALUE. Both >> should evaluate to the same value but I think it would be nice if the >> same thing is used in both places. Perhaps you can fix that up when >> applying? > > Yes, I'll do that. Following up on this series. I do not see it queued anywhere in the linux-pm [0] tree. I would like to have this in the v6.3 merge window if possible. [0] https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/
On Mon, Jan 30, 2023 at 3:18 PM Pratyush Yadav <ptyadav@amazon.de> wrote: > > Hi Rafael, > > On Thu, Dec 29 2022, Rafael J. Wysocki wrote: > > > On Thu, Dec 29, 2022 at 1:58 PM Pratyush Yadav <ptyadav@amazon.de> wrote: > >> > >> Hi Rafael, > >> > >> On Wed, Dec 28 2022, Rafael J. Wysocki wrote: > >> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > >> > > >> > When _PPC returns 0, it means that the CPU frequency is not limited by > >> > the platform firmware, so make acpi_processor_get_platform_limit() > >> > update the frequency QoS request used by it to "no limit" in that case. > >> > > >> > This addresses a problem with limiting CPU frequency artificially on > >> > some systems after CPU offline/online to the frequency that corresponds > >> > to the first entry in the _PSS return package. > >> > > >> > Reported-by: Pratyush Yadav <ptyadav@amazon.de> > >> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > >> > --- > [...] > >> > >> One small thing I noticed: in acpi_processor_ppc_init() "no limit" value > >> is set to INT_MAX and here it is set to FREQ_QOS_MAX_DEFAULT_VALUE. Both > >> should evaluate to the same value but I think it would be nice if the > >> same thing is used in both places. Perhaps you can fix that up when > >> applying? > > > > Yes, I'll do that. > > Following up on this series. I do not see it queued anywhere in the > linux-pm [0] tree. I would like to have this in the v6.3 merge window if > possible. > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/ It's already in the mainline: e8a0e30b742f cpufreq: intel_pstate: Drop ACPI _PSS states table patching 99387b016022 ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily c02d5feb6e2f ACPI: processor: perflib: Use the "no limit" frequency QoS
Hi Rafael, On Mon, Jan 30 2023, Rafael J. Wysocki wrote: > On Mon, Jan 30, 2023 at 3:18 PM Pratyush Yadav <ptyadav@amazon.de> wrote: >> >> Hi Rafael, >> >> On Thu, Dec 29 2022, Rafael J. Wysocki wrote: >> >> > On Thu, Dec 29, 2022 at 1:58 PM Pratyush Yadav <ptyadav@amazon.de> wrote: >> >> >> >> Hi Rafael, >> >> >> >> On Wed, Dec 28 2022, Rafael J. Wysocki wrote: >> >> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> >> > >> >> > When _PPC returns 0, it means that the CPU frequency is not limited by >> >> > the platform firmware, so make acpi_processor_get_platform_limit() >> >> > update the frequency QoS request used by it to "no limit" in that case. >> >> > >> >> > This addresses a problem with limiting CPU frequency artificially on >> >> > some systems after CPU offline/online to the frequency that corresponds >> >> > to the first entry in the _PSS return package. >> >> > >> >> > Reported-by: Pratyush Yadav <ptyadav@amazon.de> >> >> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> >> > --- >> [...] >> >> >> >> One small thing I noticed: in acpi_processor_ppc_init() "no limit" value >> >> is set to INT_MAX and here it is set to FREQ_QOS_MAX_DEFAULT_VALUE. Both >> >> should evaluate to the same value but I think it would be nice if the >> >> same thing is used in both places. Perhaps you can fix that up when >> >> applying? >> > >> > Yes, I'll do that. >> >> Following up on this series. I do not see it queued anywhere in the >> linux-pm [0] tree. I would like to have this in the v6.3 merge window if >> possible. >> >> [0] https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/ > > It's already in the mainline: > > e8a0e30b742f cpufreq: intel_pstate: Drop ACPI _PSS states table patching > 99387b016022 ACPI: processor: perflib: Avoid updating frequency QoS > unnecessarily > c02d5feb6e2f ACPI: processor: perflib: Use the "no limit" frequency QoS Hmm, I skimmed through the git log and did not spot any of these. Seems like they were buried deeper in the logs due to merges. I can see them now. My bad.
On Mon, 2023-01-30 at 15:58 +0100, Rafael J. Wysocki wrote: > On Mon, Jan 30, 2023 at 3:18 PM Pratyush Yadav <ptyadav@amazon.de> > wrote: > > > > [...] > > [0] > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/ > > It's already in the mainline: > > e8a0e30b742f cpufreq: intel_pstate: Drop ACPI _PSS states table > patching > 99387b016022 ACPI: processor: perflib: Avoid updating frequency QoS > unnecessarily > c02d5feb6e2f ACPI: processor: perflib: Use the "no limit" frequency > QoS I am checking 6.2-rc8. I don't see these commits. The last commit in mainline is git log --oneline drivers/acpi/processor_perflib.c f1a70bac90ca ACPI: processor: perflib: Adjust acpi_processor_notify_smm() return value Whereas linux-pm tree it is : git log --oneline drivers/acpi/processor_perflib.c 99387b016022 ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily c02d5feb6e2f ACPI: processor: perflib: Use the "no limit" frequency QoS f1a70bac90ca ACPI: processor: perflib: Adjust acpi_processor_notify_smm() return value Thanks, Srinivas
On Tue, Feb 14, 2023 at 2:40 PM srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote: > > On Mon, 2023-01-30 at 15:58 +0100, Rafael J. Wysocki wrote: > > On Mon, Jan 30, 2023 at 3:18 PM Pratyush Yadav <ptyadav@amazon.de> > > wrote: > > > > > > > > [...] > > > > [0] > > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/ > > > > It's already in the mainline: > > > > e8a0e30b742f cpufreq: intel_pstate: Drop ACPI _PSS states table > > patching > > 99387b016022 ACPI: processor: perflib: Avoid updating frequency QoS > > unnecessarily > > c02d5feb6e2f ACPI: processor: perflib: Use the "no limit" frequency > > QoS > > I am checking 6.2-rc8. > I don't see these commits. You are right, they are in linux-next only, sorry for the confusion. I'm going to push them for 6.3-rc1 this week, though.
On Tue, 2023-02-14 at 14:57 +0100, Rafael J. Wysocki wrote: > On Tue, Feb 14, 2023 at 2:40 PM srinivas pandruvada > <srinivas.pandruvada@linux.intel.com> wrote: > > > > On Mon, 2023-01-30 at 15:58 +0100, Rafael J. Wysocki wrote: > > > On Mon, Jan 30, 2023 at 3:18 PM Pratyush Yadav > > > <ptyadav@amazon.de> > > > wrote: > > > > > > > > > > > > [...] > > > > > > [0] > > > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/ > > > > > > It's already in the mainline: > > > > > > e8a0e30b742f cpufreq: intel_pstate: Drop ACPI _PSS states table > > > patching > > > 99387b016022 ACPI: processor: perflib: Avoid updating frequency > > > QoS > > > unnecessarily > > > c02d5feb6e2f ACPI: processor: perflib: Use the "no limit" > > > frequency > > > QoS > > > > I am checking 6.2-rc8. > > I don't see these commits. > > You are right, they are in linux-next only, sorry for the confusion. > > I'm going to push them for 6.3-rc1 this week, though. I don't think they are marked for stable. Can we add that? Thanks, Srinivas
On Tue, Feb 14, 2023 at 3:25 PM srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote: > > On Tue, 2023-02-14 at 14:57 +0100, Rafael J. Wysocki wrote: > > On Tue, Feb 14, 2023 at 2:40 PM srinivas pandruvada > > <srinivas.pandruvada@linux.intel.com> wrote: > > > > > > On Mon, 2023-01-30 at 15:58 +0100, Rafael J. Wysocki wrote: > > > > On Mon, Jan 30, 2023 at 3:18 PM Pratyush Yadav > > > > <ptyadav@amazon.de> > > > > wrote: > > > > > > > > > > > > > > > > [...] > > > > > > > > [0] > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/ > > > > > > > > It's already in the mainline: > > > > > > > > e8a0e30b742f cpufreq: intel_pstate: Drop ACPI _PSS states table > > > > patching > > > > 99387b016022 ACPI: processor: perflib: Avoid updating frequency > > > > QoS > > > > unnecessarily > > > > c02d5feb6e2f ACPI: processor: perflib: Use the "no limit" > > > > frequency > > > > QoS > > > > > > I am checking 6.2-rc8. > > > I don't see these commits. > > > > You are right, they are in linux-next only, sorry for the confusion. > > > > I'm going to push them for 6.3-rc1 this week, though. > I don't think they are marked for stable. Can we add that? I'd rather not rebase them for that. It is still possible to send an inclusion request to -stable when then get into the mainline.
Index: linux-pm/drivers/acpi/processor_perflib.c =================================================================== --- linux-pm.orig/drivers/acpi/processor_perflib.c +++ linux-pm/drivers/acpi/processor_perflib.c @@ -53,6 +53,8 @@ static int acpi_processor_get_platform_l { acpi_status status = 0; unsigned long long ppc = 0; + s32 qos_value; + int index; int ret; if (!pr) @@ -72,17 +74,27 @@ static int acpi_processor_get_platform_l } } + index = ppc; + pr_debug("CPU %d: _PPC is %d - frequency %s limited\n", pr->id, - (int)ppc, ppc ? "" : "not"); + index, index ? "is" : "is not"); - pr->performance_platform_limit = (int)ppc; + pr->performance_platform_limit = index; if (ppc >= pr->performance->state_count || unlikely(!freq_qos_request_active(&pr->perflib_req))) return 0; - ret = freq_qos_update_request(&pr->perflib_req, - pr->performance->states[ppc].core_frequency * 1000); + /* + * If _PPC returns 0, it means that all of the available states can be + * used ("no limit"). + */ + if (index == 0) + qos_value = FREQ_QOS_MAX_DEFAULT_VALUE; + else + qos_value = pr->performance->states[index].core_frequency * 1000; + + ret = freq_qos_update_request(&pr->perflib_req, qos_value); if (ret < 0) { pr_warn("Failed to update perflib freq constraint: CPU%d (%d)\n", pr->id, ret);