Re: [PATCH v6 16/19] xen/cpufreq: introduce GET_CPUFREQ_CPPC sub-op

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.07.2025 16:17, Jason Andryuk wrote:
> On 2025-07-24 09:31, Jan Beulich wrote:
>> On 11.07.2025 05:51, Penny Zheng wrote:
>>> In amd-cppc passive mode, it's Xen governor which is responsible for
>>> performance tuning, so governor and CPPC could co-exist. That is, both
>>> governor-info and CPPC-info need to be printed together via xenpm tool.
>>>
>>> If we tried to still put it in "struct xen_get_cpufreq_para" (e.g. just move
>>> out of union), "struct xen_get_cpufreq_para" will enlarge too much to 
>>> further
>>> make xen_sysctl.u exceed 128 bytes.
>>> So we introduce a new sub-op GET_CPUFREQ_CPPC to specifically print
>>> CPPC-related para.
>>>
>>> Signed-off-by: Penny Zheng <Penny.Zheng@xxxxxxx>
> 
>>>   void scaling_max_freq_func(int argc, char *argv[])
>>>   {
>>>       int cpuid = -1, freq = -1;
>>> @@ -1576,6 +1622,7 @@ struct {
>>>       { "get-cpufreq-average", cpufreq_func },
>>>       { "start", start_gather_func },
>>>       { "get-cpufreq-para", cpufreq_para_func },
>>> +    { "get-cpufreq-cppc", cppc_para_func },
>>
>> Didn't Jason also suggest that we would better not introduce a new command, 
>> but
>> rather make get-cpufreq-para invoke GET_CPUFREQ_CPPC as needed? Considering 
>> that
>> as per patch 15 the same information is already printed, I think I'm a little
>> lost with the need for this separate operation (and command), and then also 
>> with
>> the need for patch 15.
> 
> Yes, but I thought I was repeating your suggestion, Jan :)

That's what I tried to express using "also" ;-)

Jan