From: Christian Loehle <christian.loehle@arm.com>
To: Lifeng Zheng <zhenglifeng1@huawei.com>,
rafael@kernel.org, viresh.kumar@linaro.org,
saket.dumbre@intel.com, lenb@kernel.org, ionela.voinescu@arm.com,
zhanjie9@hisilicon.com, pierre.gondois@arm.com,
sumitg@nvidia.com
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, acpica-devel@lists.linux.dev,
linuxarm@huawei.com, yubowen8@huawei.com,
zhangpengjie2@huawei.com, wangzhi12@huawei.com,
linhongye@h-partners.com
Subject: Re: [PATCH v4 0/8] ACPI: CPPC: Resource Priority Register support and sysfs interface
Date: Mon, 28 Sep 2026 14:51:00 +0100 [thread overview]
Message-ID: <2c6f79b9-2830-4a56-b4bb-8ae728eb41ee@arm.com> (raw)
In-Reply-To: <20260922124121.3426219-1-zhenglifeng1@huawei.com>
On 9/22/26 13:41, Lifeng Zheng wrote:
> This series implements support for the CPPC v4 Resource Priority Register
> mechanism defined in ACPI 6.6, Section 8.4.6.1.2.7, and exposes it to
> userspace via sysfs.
>
> Resource Priority allows OSPM to control the relative priority among
> processors for shared resources. OSPM can utilize these sysfs interfaces
> to configure resource priorities, allowing resources to be preferentially
> allocated to more important tasks.
>
> The controlled resource types include processor boost, throttle, L2 cache,
> L3 cache, and memory bandwidth. Each Resource Priority group consists of:
> > - CONTROLLED_RESOURCES: which resource types the group affects
> - ENABLE_VALUE / ENABLE_REGISTER: enable/disable the group
> - PRIORITY_COUNT / PRIORITY_REGISTER: read/write the priority level
>
> The patch series is organized in three parts:
>
> - patches 1-4 extend the CPPC data structures and _CPC parser to handle
> Package-type entries and parse Resource Priority sub-packages into
> structured descriptors.
>
> - patches 5-7 refactor existing register I/O helpers to support direct
> register access and add accessor functions for Resource Priority
> attributes (enable, priority count, priority value).
>
> - patch 8 creates a "resource_priority" sysfs hierarchy under each
> cpufreq policy to expose the Resource Priority attributes to userspace.
>
> Changelog:
> v4:
> - Patch 7: Set *num_resources to 0 when controlled resources number
> invalid in cppc_get_resource_priority_resources(), therefore, the caller
> will not read the unassigned `resources` pointer.
> - Patch 8: Remove kfree() from the error path of
> cppc_create_res_prio_sysfs() because cppc_res_prio_release() will do it.
>
> v3:
> - Patch 2: Add the (i - 2) == RESOURCE_PRIORITY condition back to ensure
> the new code behaves the same as the original.
> - Patch 4: Assign -ENODATA to ret when an unexpected ACPI_TYPE_PACKAGE
> appears.
> - Patch 5: Initialize the `optional` field of the remaining cpc_regs to
> true so that they are treated as unsupported.
> - Patch 8: Call cppc_cpufreq_cpu_fie_exit() and set perf to lowest_perf
> when cppc_create_res_prio_sysfs() fails. Call kobject_put() and kfree()
> when kobject_init_and_add() fails in cppc_create_res_prio_sysfs().
> - Link: https://lore.kernel.org/all/20260812015217.74598-1-zhenglifeng1@huawei.com/
>
> v2:
> - Patch 1: Revert changes to the CPC_SUPPORTED() macro.
> - Link: https://lore.kernel.org/all/20260804085042.4118193-1-zhenglifeng1@huawei.com/
>
> v1:
> - Link: https://lore.kernel.org/all/20260717024502.3520445-1-zhenglifeng1@huawei.com/
>
> ---
>
> RFC: sysfs placement
>
> The sysfs interface is currently placed under /sys/devices/system/cpu/cpufreq/
> (i.e. the cpufreq policy directory). I am unsure whether this is the best
> location and would appreciate reviewer feedback.
>
> The concern is that Resource Priority covers resource types beyond CPU
> frequency control:
>
> - PROCESSOR_BOOST, PROCESSOR_THROTTLE -- clearly CPU-frequency related
> - L2_CACHE, L3_CACHE -- cache partitioning, not frequency
> - MEMORY_BANDWIDTH -- memory QoS, not frequency
>
> Placing the attributes under cpufreq makes sense for boost/throttle but
> feels semantically wrong for cache and memory bandwidth resources.
>
> I would appreciate feedback on whether cpufreq is the right home for
> this interface, or whether a different location would be more appropriate.
Another issue is regarding adjacent interfaces (Intel-RDT, AMD-QoS, Arm-MPAM,
RISCV-CBQR for memory and cache. I'm hoping no sane platform advertises both,
but should the kernel sanitize these?
Additionally what if we ever do want to be more 'clever' in the kernel about
aggregating these hints of "boost-worthiness" of tasks/CPUs, do we just disable
the low level sysfs controls here then?
>
> Lifeng Zheng (8):
> ACPI: CPPC: Prepare cpc_register_resource for Package-type entries
> ACPI: CPPC: Refactor element parsing into parse_cpc_element()
> ACPI: CPPC: Refactor resource cleanup into free_reg_resource()
> ACPI: CPPC: Parse Resource Priority Register entries from _CPC package
> ACPI: CPPC: Store optional flag in cpc_register_resource
> ACPI: CPPC: Factor out cpc_read_reg() and cpc_write_reg()
> ACPI: CPPC: Add Resource Priority accessors
> cpufreq: cppc: Expose Resource Priority attributes via sysfs
>
> drivers/acpi/cppc_acpi.c | 719 +++++++++++++++++++++++++++------
> drivers/cpufreq/cppc_cpufreq.c | 281 ++++++++++++-
> include/acpi/cppc_acpi.h | 60 +++
> 3 files changed, 930 insertions(+), 130 deletions(-)
>
prev parent reply other threads:[~2026-09-28 13:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 12:41 Lifeng Zheng
2026-09-22 12:41 ` [PATCH v4 1/8] ACPI: CPPC: Prepare cpc_register_resource for Package-type entries Lifeng Zheng
2026-09-22 12:41 ` [PATCH v4 2/8] ACPI: CPPC: Refactor element parsing into parse_cpc_element() Lifeng Zheng
2026-09-22 12:41 ` [PATCH v4 3/8] ACPI: CPPC: Refactor resource cleanup into free_reg_resource() Lifeng Zheng
2026-09-22 12:41 ` [PATCH v4 4/8] ACPI: CPPC: Parse Resource Priority Register entries from _CPC package Lifeng Zheng
2026-09-28 14:06 ` Christian Loehle
2026-09-22 12:41 ` [PATCH v4 5/8] ACPI: CPPC: Store optional flag in cpc_register_resource Lifeng Zheng
2026-09-22 12:41 ` [PATCH v4 6/8] ACPI: CPPC: Factor out cpc_read_reg() and cpc_write_reg() Lifeng Zheng
2026-09-22 12:41 ` [PATCH v4 7/8] ACPI: CPPC: Add Resource Priority accessors Lifeng Zheng
2026-09-28 13:59 ` Christian Loehle
2026-09-22 12:41 ` [PATCH v4 8/8] cpufreq: cppc: Expose Resource Priority attributes via sysfs Lifeng Zheng
2026-09-25 20:23 ` [PATCH v4 0/8] ACPI: CPPC: Resource Priority Register support and sysfs interface Rafael J. Wysocki (Intel)
2026-09-28 13:51 ` Christian Loehle [this message]
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=2c6f79b9-2830-4a56-b4bb-8ae728eb41ee@arm.com \
--to=christian.loehle@arm.com \
--cc=acpica-devel@lists.linux.dev \
--cc=ionela.voinescu@arm.com \
--cc=lenb@kernel.org \
--cc=linhongye@h-partners.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=pierre.gondois@arm.com \
--cc=rafael@kernel.org \
--cc=saket.dumbre@intel.com \
--cc=sumitg@nvidia.com \
--cc=viresh.kumar@linaro.org \
--cc=wangzhi12@huawei.com \
--cc=yubowen8@huawei.com \
--cc=zhangpengjie2@huawei.com \
--cc=zhanjie9@hisilicon.com \
--cc=zhenglifeng1@huawei.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
all inboxes | Powered by JetHome®