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 :)
xenpm's show_cpufreq_para_by_cpuid() would do something like:
show_cpufreq_para_by_cpuid() {
xc_get_cpufreq_para()
hw_auto = HWP || CPPC
if ( hw_auto ) {
xc_get_cppc_para()
print_cppc_para()
} else
print_cpufreq_para()
}
Would that work?
That way the single `xenpm get-cpufreq-para` would return the current
cpufreq data without the user needed to know what is running.
Regards,
Jason
