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.zh...@amd.com>
>
>>> 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
