From: Punit Agrawal <punit.agrawal@bytedance.com>
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: Punit Agrawal <punit.agrawal@bytedance.com>,
linux-pm@vger.kernel.org, rafael@kernel.org, lenb@kernel.org,
viresh.kumar@linaro.org, robert.moore@intel.com,
devel@acpica.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] ACPI: CPPC: Disable FIE if registers in PCC regions
Date: Mon, 01 Aug 2022 13:32:51 +0100 [thread overview]
Message-ID: <87tu6wjg98.fsf@stealth> (raw)
In-Reply-To: <a0bdc45a-c5c6-65ba-1ab8-e52dd26652d7@arm.com> (Jeremy Linton's message of "Fri, 29 Jul 2022 10:20:46 -0500")
Jeremy Linton <jeremy.linton@arm.com> writes:
> Hi,
>
> On 7/29/22 07:59, Punit Agrawal wrote:
>> Hi Jeremy,
>> One comment / query below.
>> Jeremy Linton <jeremy.linton@arm.com> writes:
>>
>>> PCC regions utilize a mailbox to set/retrieve register values used by
>>> the CPPC code. This is fine as long as the operations are
>>> infrequent. With the FIE code enabled though the overhead can range
>>> from 2-11% of system CPU overhead (ex: as measured by top) on Arm
>>> based machines.
>>>
>>> So, before enabling FIE assure none of the registers used by
>>> cppc_get_perf_ctrs() are in the PCC region. Furthermore lets also
>>> enable a module parameter which can also disable it at boot or module
>>> reload.
>>>
>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>> ---
>>> drivers/acpi/cppc_acpi.c | 41 ++++++++++++++++++++++++++++++++++
>>> drivers/cpufreq/cppc_cpufreq.c | 19 ++++++++++++----
>>> include/acpi/cppc_acpi.h | 5 +++++
>>> 3 files changed, 61 insertions(+), 4 deletions(-)
>>>
>> [...]
>>
>>> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
>>> index 24eaf0ec344d..ed607e27d6bb 100644
>>> --- a/drivers/cpufreq/cppc_cpufreq.c
>>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>> [...]
>>
>>> @@ -229,7 +233,12 @@ static void __init cppc_freq_invariance_init(void)
>>> };
>>> int ret;
>>> - if (cppc_cpufreq_driver.get == hisi_cppc_cpufreq_get_rate)
>>> + if (cppc_perf_ctrs_in_pcc()) {
>>> + pr_debug("FIE not enabled on systems with registers in PCC\n");
>> The message should probably be promoted to a pr_info() and exposed
>> as
>> part of the kernel logs. It is a change in the default behaviour we've
>> had until now. The message will provide some hint about why it was
>> disabled.
>> Thoughts?
>
> I personally flip flopped between making it pr_info or pr_debug and
> settled on debug because no one else was complaining about the
> cppc_fie consumption. Which to me, meant that the users of platforms
> utilizing PCC regions weren't sensitive to the problem, or weren't yet
> running a distro/kernel with it enabled, or any number of other
> reasons why the problem wasn't getting more attention. Mostly I
> concluded the FIE code hadn't shown up in "enterprise" distros yet..
I too was thinking that likely enterprise users haven't started digging
into the performance impact of enabling frequency invariance.
> But, yah, if no one is going to complain about the extra messages
> pr_info() is a better plan.
Thanks! I'll look out for the updated patch.
FIE was designed to improve load balancing (and arguably fairness
too). Hopefully, the message will aid users in looking more closely and
complain to system vendor / upstream if it matters to their workloads.
next prev parent reply other threads:[~2022-08-01 12:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-28 22:10 [PATCH v2 0/1] Disable FIE on machines with slow counters Jeremy Linton
2022-07-28 22:10 ` [PATCH v2 1/1] ACPI: CPPC: Disable FIE if registers in PCC regions Jeremy Linton
2022-07-29 12:59 ` Punit Agrawal
2022-07-29 15:20 ` Jeremy Linton
2022-08-01 12:32 ` Punit Agrawal [this message]
2022-08-10 12:29 ` Lukasz Luba
2022-08-10 12:51 ` Ionela Voinescu
2022-08-10 13:56 ` Lukasz Luba
2022-08-10 17:43 ` Jeremy Linton
2022-08-10 14:08 ` Jeremy Linton
2022-08-10 14:32 ` Lukasz Luba
2022-08-10 18:04 ` Jeremy Linton
2022-08-11 7:29 ` Lukasz Luba
2022-08-10 14:30 ` Jeremy Linton
2022-08-10 14:37 ` Lukasz Luba
2022-08-10 15:32 ` Pierre Gondois
2022-08-11 7:45 ` Lukasz Luba
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=87tu6wjg98.fsf@stealth \
--to=punit.agrawal@bytedance.com \
--cc=devel@acpica.org \
--cc=jeremy.linton@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--cc=viresh.kumar@linaro.org \
/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