From: Mel Gorman <mgorman@techsingularity.net>
To: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>,
linux-kernel@vger.kernel.org, Len Brown <lenb@kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
rafael@kernel.org, Linux PM <linux-pm@vger.kernel.org>
Subject: Re: ACPI _CST introduced performance regresions on Haswll
Date: Thu, 15 Oct 2020 19:34:10 +0100 [thread overview]
Message-ID: <20201015183410.GU3227@techsingularity.net> (raw)
In-Reply-To: <20201014223703.GT3227@techsingularity.net>
> Yes, it's well hidden but it's there. If the profile is made custom, then
> the p-states can be selected and "custom" default enables C6 but not C3
> (there is a note saying that it's not recommended for that CPU). If I
> then switch it back to the normal profile, the c-states are not restored
> so this is a one-way trip even if you disable the c-state in custom,
> reboot, switch back, reboot. Same if the machine is reset to "optimal
> default settings". Yey for BIOS developers.
>
> This means I have a limited number of attempts to do something about
> this. 2 machines can no longer reproduce the problem reliably.
>
Turns out I didn't even have that. On another machine (same model,
same cpu, different BIOS that cannot be updated), enabling the C6 state
still did not enable it on boot and dmesg complained about CST not being
usable. This is weird because one would expect that if CST was unusable
that it would be the same as use_acpi == false.
This could potentially be if the ACPI tables are unsuitable due to bad
bad FFH information for a lower c-state. If _CST is not found or usable,
should acpi_state_table.count be reset to go back to the old behaviour?
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 13600c403035..3b84f8631b40 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -1261,6 +1261,7 @@ static bool intel_idle_acpi_cst_extract(void)
return true;
}
+ acpi_state_table.count = 0;
pr_debug("ACPI _CST not found or not usable\n");
return false;
}
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2020-10-15 18:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 8:36 ACPI _CST introduced performance regresions on Haswll Mel Gorman
2020-10-06 16:00 ` Rafael J. Wysocki
2020-10-06 19:03 ` Mel Gorman
2020-10-06 19:29 ` Rafael J. Wysocki
2020-10-06 21:18 ` Mel Gorman
2020-10-07 15:45 ` Rafael J. Wysocki
2020-10-08 9:09 ` Mel Gorman
2020-10-08 17:15 ` Rafael J. Wysocki
2020-10-08 17:34 ` Mel Gorman
2020-10-13 18:55 ` Rafael J. Wysocki
2020-10-14 22:37 ` Mel Gorman
2020-10-15 18:34 ` Mel Gorman [this message]
2020-10-16 13:41 ` Rafael J. Wysocki
2020-10-16 14:09 ` Mel Gorman
2020-10-16 15:29 ` Rafael J. Wysocki
2020-10-06 19:47 ` Mel Gorman
2020-10-07 15:40 ` Rafael J. Wysocki
2020-10-07 19:23 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201015183410.GU3227@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).