Linux Power Management development
 help / color / mirror / Atom feed
From: Christian Loehle <christian.loehle@arm.com>
To: "Rafael J. Wysocki (Intel)" <rafael@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jie Zhan <zhanjie9@hisilicon.com>,
	Lifeng Zheng <zhenglifeng1@huawei.com>,
	Pierre Gondois <pierre.gondois@arm.com>,
	Sumit Gupta <sumitg@nvidia.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Ionela Voinescu <ionela.voinescu@arm.com>,
	Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Subject: Re: [PATCH 0/3] ACPI: CPPC: Reduce .target() callback overhead
Date: Mon, 3 Aug 2026 21:46:58 +0100	[thread overview]
Message-ID: <e672b3f1-1a43-4f20-a02c-384b283883c9@arm.com> (raw)
In-Reply-To: <CAJZ5v0jFvXKTO7MnC5GHYo85E6NwXQUXRDmmkq1i9BtSbQueAg@mail.gmail.com>

On 8/3/26 15:54, Rafael J. Wysocki (Intel) wrote:
> On Mon, Aug 3, 2026 at 4:07 PM Christian Loehle
> <christian.loehle@arm.com> wrote:
>>
>> On 7/24/26 14:42, Christian Loehle wrote:
>>> cppc-cpufreq reaches cppc_set_perf() from every target callback.  For
>>> direct SystemMemory controls, that path currently does several steps
>>> which are unnecessary once the immutable _CPC layout is known:
>>>
>>>   - a full-width write first reads the access unit and merges the value.
>>>   - every write takes the descriptor's RMW lock, even when its access unit
>>>     is not shared with another _CPC entry.
>>>   - cppc_set_perf() evaluates the same three PCC predicates at each phase
>>>     of the transaction.
>>>
>>> Remove those costs while retaining the existing conservative paths for
>>> partial fields, overlapping or malformed access units, and PCC controls.
>>>
>>> The series was tested on Arm Power-Orion O6 and AmpereOne systems using
>>> cppc-cpufreq and schedutil.  An rt-app task pinned to one CPU ran for
>>> 500 us every 2 ms with uclamp.min=512, for 5000 periods per run.  schedutil
>>> rate_limit_us was 1000.  cppc_cpufreq_fast_switch() latency was measured
>>> for 100 ten-second runs.  Each sample is the mean callback latency within
>>> one run, and the table reports the median and sample standard deviation
>>> of those samples.
>>>
>>> Orion O6               median       stdev       callbacks
>>> baseline               5703 ns      307 ns       188017
>>> complete series        5023 ns      240 ns       188209
>>> ==> 680 ns (11.9%) reduction
>>>
>>> AmpereOne              median       stdev
>>> baseline               2090 ns      157 ns
>>> complete series      1907.5 ns      140 ns
>>> ==> 182.5 ns (8.7%) reduction
>>>
>>> The cumulative intermediate results on the Orion O6 attribute roughly half
>>> of the gain to each of the first two patches: avoiding the read reduced
>>> the median by 284 ns (5.0%), and avoiding the lock reduced it by another
>>> 336 ns (6.2%).
>>> Together they account for 620 ns of the 680 ns total reduction.
>>>
>>> With the same arm64 configuration and GCC 11.4, caching the PCC predicate
>>> also reduces cppc_set_perf() from 1124 to 884 bytes.  The generated
>>> function has 60 fewer instructions, 17 fewer loads and 20 fewer branches.
>>>
>>> This series is based on the CPPC fixes posted at (already queued):
>>> https://lore.kernel.org/lkml/20260722093825.1030594-1-christian.loehle@arm.com/
>>>
>>> and the separately posted fix still under review:
>>> https://lore.kernel.org/lkml/20260724104042.1481804-1-christian.loehle@arm.com/
>>>
>>> PS:
>>> There's a final optimization that I actually wanted to make but decided to
>>> split it out for now as it somewhat replicated Sumit's series:
>>> Skipping redundant perf ctrl writes in cpufreq-cppc if registers are non-PCC
>>> and !shared (because the values are unchanged, the
>>> !autonomous-common-case), but that requires the driver to have a more
>>> complex caching- and atomic-updating machinery in place, similar to
>>> hotplug. As opposed to this series the optimization would be for the
>>> microcontroller handling the CPPC requests, which may be shared across
>>> many CPUs and therefore redundant requests can increase the dvfs
>>> transition latency.
>>> That patch will follow once Sumit's is queued:
>>> https://lore.kernel.org/lkml/20260716153820.2007095-1-sumitg@nvidia.com/
>>>
>>> Christian Loehle (3):
>>>   ACPI: CPPC: Avoid unnecessary reads for full-width writes
>>>   ACPI: CPPC: Avoid locking standalone full-width registers
>>>   ACPI: CPPC: Evaluate performance-control PCC use once
>>>
>>>  drivers/acpi/cppc_acpi.c | 135 +++++++++++++++++++++++++++++++--------
>>>  include/acpi/cppc_acpi.h |   5 +-
>>>  2 files changed, 113 insertions(+), 27 deletions(-)
>>>
>>>
>>> base-commit: 1590cf0329716306e948a8fc29f1d3ee87d3989f
>>> prerequisite-patch-id: 4c1f4063800e3658717eb77e43af13dad52d55cc
>>> prerequisite-patch-id: 5c40d9f099543123c9b904d18ce651e740fbefb8
>>> prerequisite-patch-id: 7202391dca8f31f9eb8f6d59fc753b3ce665e103
>>
>>
>> I was about the rebase and resend this series but noticed it still applies cleanly
>> on 7.2-rc6 + ACPI: CPPC: Avoid Desired Performance reads on ACPI 6.6+
>> https://lore.kernel.org/all/cover.1785749175.git.christian.loehle@arm.com/
>>
>> Any comments on this?
> 
> Sashiko says that it couldn't apply this series:
> 
> https://sashiko.dev/#/patchset/20260724134251.1632824-1-christian.loehle%40arm.com
> 
> Would it apply on top of plain 7.2-rc6?  If so, can you please rebase
> and resend it?  Or is it linux-next-only?

Strange, it still works for me, anything I'm missing?
Anyway I can rebase on v7.2-rc6 and rebase, the desired_perf changes are unrelated,
but here's my log FWIW:

# git checkout v7.2-rc6
# git switch -c cloehle/cppc-target-optimizations-7.2-rc6-test
# b4 am -c -o - 20260724134251.1632824-1-christian.loehle@arm.com | git am
Grabbing thread from lore.kernel.org/all/20260724134251.1632824-1-christian.loehle@arm.com/t.mbox.gz
Checking for newer revisions
Grabbing search results from lore.kernel.org
Analyzing 6 messages in the thread
Looking for additional code-review trailers on lore.kernel.org
Analyzing 0 code-review messages
Checking attestation on all messages, may take a moment...
---
  ✓ [PATCH 1/3] ACPI: CPPC: Avoid unnecessary reads for full-width writes
  ✓ [PATCH 2/3] ACPI: CPPC: Avoid locking standalone full-width registers
  ✓ [PATCH 3/3] ACPI: CPPC: Evaluate performance-control PCC use once
  ---
  ✓ Signed: DKIM/arm.com
---
Total patches: 3
---
 Link: https://lore.kernel.org/r/20260724134251.1632824-1-christian.loehle@arm.com
 Base: using specified base-commit 1590cf0329716306e948a8fc29f1d3ee87d3989f
       git checkout -b 20260724_christian_loehle_arm_com 1590cf0329716306e948a8fc29f1d3ee87d3989f
Applying: ACPI: CPPC: Avoid unnecessary reads for full-width writes
Applying: ACPI: CPPC: Avoid locking standalone full-width registers
Applying: ACPI: CPPC: Evaluate performance-control PCC use once

# git log --oneline
86f53dfeddb6 (HEAD -> cloehle/cppc-target-optimizations-7.2-rc6-test) ACPI: CPPC: Evaluate performance-control PCC use once
61378f475006 ACPI: CPPC: Avoid locking standalone full-width registers
0c5b12480412 ACPI: CPPC: Avoid unnecessary reads for full-width writes
075b74841bd0 (tag: v7.2-rc6, origin/master, origin/HEAD) Linux 7.2-rc6


  reply	other threads:[~2026-08-03 20:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 13:42 [PATCH 0/3] ACPI: CPPC: Reduce .target() callback overhead Christian Loehle
2026-07-24 13:42 ` [PATCH 1/3] ACPI: CPPC: Avoid unnecessary reads for full-width writes Christian Loehle
2026-07-24 13:42 ` [PATCH 2/3] ACPI: CPPC: Avoid locking standalone full-width registers Christian Loehle
2026-07-24 13:42 ` [PATCH 3/3] ACPI: CPPC: Evaluate performance-control PCC use once Christian Loehle
2026-08-03 14:07 ` [PATCH 0/3] ACPI: CPPC: Reduce .target() callback overhead Christian Loehle
2026-08-03 14:54   ` Rafael J. Wysocki (Intel)
2026-08-03 20:46     ` Christian Loehle [this message]
2026-08-03 21:01       ` Christian Loehle

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=e672b3f1-1a43-4f20-a02c-384b283883c9@arm.com \
    --to=christian.loehle@arm.com \
    --cc=ionela.voinescu@arm.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pierre.gondois@arm.com \
    --cc=rafael@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=sumitg@nvidia.com \
    --cc=viresh.kumar@linaro.org \
    --cc=zhanjie9@hisilicon.com \
    --cc=zhenglifeng1@huawei.com \
    --cc=zhongqiu.han@oss.qualcomm.com \
    /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