linux-kernel - Re: [PATCH v7 4/7] ACPI: CPPC: add APIs and sysfs interface for min/max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e7570bc3-5420-4743-8a75-8602559ca235@amd.com>
Date: Tue, 3 Feb 2026 14:28:50 -0600
From: Mario Limonciello <mario.limonciello@....com>
To: "Rafael J. Wysocki" <rafael@...nel.org>, Sumit Gupta <sumitg@...dia.com>
Cc: Russell Haley <yumpusamongus@...il.com>,
 "zhenglifeng (A)" <zhenglifeng1@...wei.com>, pierre.gondois@....com,
 viresh.kumar@...aro.org, ionela.voinescu@....com, corbet@....net,
 rdunlap@...radead.org, ray.huang@....com, gautham.shenoy@....com,
 perry.yuan@....com, zhanjie9@...ilicon.com, linux-pm@...r.kernel.org,
 linux-acpi@...r.kernel.org, linux-doc@...r.kernel.org,
 acpica-devel@...ts.linux.dev, linux-kernel@...r.kernel.org,
 linux-tegra@...r.kernel.org, treding@...dia.com, jonathanh@...dia.com,
 vsethi@...dia.com, ksitaraman@...dia.com, sanjayc@...dia.com,
 nhartman@...dia.com, bbasu@...dia.com
Subject: Re: [PATCH v7 4/7] ACPI: CPPC: add APIs and sysfs interface for
 min/max_perf

On 2/3/26 2:24 PM, Rafael J. Wysocki wrote:
> On Tue, Feb 3, 2026 at 3:32 PM Sumit Gupta <sumitg@...dia.com> wrote:
>>
>>
>> On 03/02/26 18:24, Rafael J. Wysocki wrote:
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> On Tue, Feb 3, 2026 at 1:45 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>>>> On Tue, Feb 3, 2026 at 10:41 AM Sumit Gupta <sumitg@...dia.com> wrote:
>>>>>>>> Hi Sumit,
>>>>>>>>
>>>>>>>> I am thinking that maybe it is better to call these two sysfs interface
>>>>>>>> 'min_freq' and 'max_freq' as users read and write khz instead of raw
>>>>>>>> value.
>>>>>>> Thanks for the suggestion.
>>>>>>> Kept min_perf/max_perf to match the CPPC register names
>>>>>>> (MIN_PERF/MAX_PERF), making it clear to users familiar with
>>>>>>> CPPC what's being controlled.
>>>>>>> The kHz unit is documented in the ABI.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Sumit Gupta
>>>>>> On my x86 machine with kernel 6.18.5, the kernel is exposing raw values:
>>>>>>
>>>>>>> grep . /sys/devices/system/cpu/cpu0/acpi_cppc/*
>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/feedback_ctrs:ref:342904018856568
>>>>>> del:437439724183386
>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/guaranteed_perf:63
>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf:88
>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_freq:0
>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_nonlinear_perf:36
>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_perf:1
>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq:3900
>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_perf:62
>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/reference_perf:62
>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/wraparound_time:18446744073709551615
>>>>>>
>>>>>> It would be surprising for a nearby sysfs interface with very similar
>>>>>> names to use kHz instead.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Russell Haley
>>>>> I can rename to either of the below:
>>>>> - min/max_freq: might be confused with scaling_min/max_freq.
>>>>> - min/max_perf_freq: keeps the CPPC register association clear.
>>>>>
>>>>> Rafael, Any preferences here?
>>>> On x86 the units in CPPC are not kHz and there is no easy reliable way
>>>> to convert them to kHz.
>>>>
>>>> Everything under /sys/devices/system/cpu/cpu0/acpi_cppc/ needs to be
>>>> in CPPC units, not kHz (unless, of course, kHz are CPPC units).
>>
>>
>> In v1 [1], these controls were added under acpi_cppc sysfs.
>> After discussion, they were moved under cpufreq, and [2] was merged first.
>> The decision to use frequency scale instead of raw perf was made
>> for consistency with other cpufreq interfaces as per (v3 [3]).
>>
>> CPPC units in our case are also not in kHz. The kHz conversion uses the
>> existing cppc_perf_to_khz()/cppc_khz_to_perf() helpers which are already
>> used in cppc_cpufreq attributes. So the conversion behavior is consistent
>> with existing cpufreq interfaces.
>>
>> [1]
>> https://lore.kernel.org/lkml/076c199c-a081-4a7f-956c-f395f4d5e156@nvidia.com/
>> [2]
>> https://lore.kernel.org/all/20250507031941.2812701-1-zhenglifeng1@huawei.com/
>> [3]
>> https://lore.kernel.org/lkml/80e16de0-63e4-4ead-9577-4ebba9b1a02d@nvidia.com/
>>
>>> That said, the new attributes will show up elsewhere.
>>>
>>> So why do you need to add these things in the first place?
>>
>> Currently there's no sysfs interface to dynamically control the
>> MIN_PERF/MAX_PERF bounds when using autonomous mode. This helps
>> users tune power and performance at runtime.
> 
> So what about scaling_min_freq and scaling_max_freq?
> 
> intel_pstate uses them for an analogous purpose.

FWIW same thing for amd_pstate.