RE: [PATCH v5 00/18] amd-cppc CPU Performance Scaling Driver

["Penny, Zheng" <penny.zheng@xxxxxxx>]

[Public]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Tuesday, June 17, 2025 6:42 PM
> To: Penny, Zheng <penny.zheng@xxxxxxx>
> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>;
> Anthony PERARD <anthony.perard@xxxxxxxxxx>; Orzel, Michal
> <Michal.Orzel@xxxxxxx>; Julien Grall <julien@xxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; Juergen Gross <jgross@xxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH v5 00/18] amd-cppc CPU Performance Scaling Driver
>
> On 27.05.2025 10:48, Penny Zheng wrote:
> > amd-cppc is the AMD CPU performance scaling driver that introduces a
> > new CPU frequency control mechanism on modern AMD APU and CPU series
> > in Xen. The new mechanism is based on Collaborative Processor
> > Performance Control (CPPC) which provides finer grain frequency
> > management than legacy ACPI hardware P-States. Current AMD CPU/APU
> > platforms are using the ACPI P-states driver to manage CPU frequency
> > and clocks with switching only in 3 P-states. CPPC replaces the ACPI
> > P-states controls and allows a flexible, low-latency interface for Xen
> > to directly communicate the performance hints to hardware.
> >
> > amd_cppc driver has 2 operation modes: autonomous (active) mode, and
> > non-autonomous (passive) mode. We register different CPUFreq driver
> > for different modes, "amd-cppc" for passive mode and "amd-cppc-epp"
> > for active mode.
> >
> > The passive mode leverages common governors such as *ondemand*,
> > *performance*, etc, to manage the performance tuning. While the active
> > mode uses epp to provides a hint to the hardware if software wants to
> > bias toward performance (0x0) or energy efficiency (0xff). CPPC power
> > algorithm in hardware will automatically calculate the runtime
> > workload and adjust the realtime cpu cores frequency according to the
> > power supply and thermal, core voltage and some other hardware conditions.
> >
> > amd-cppc is enabled on passive mode with a top-level
> > `cpufreq=amd-cppc` option, while users add extra `active` flag to select 
> > active
> mode.
> >
> > With `cpufreq=amd-cppc,active`, we did a 60s sampling test to see the
> > CPU frequency change, through tweaking the energy_perf preference from
> > `xenpm set-cpufreq-cppc powersave` to `xenpm set-cpufreq-cppc performance`.
> > The outputs are as follows:
> > ```
> > Setting CPU in powersave mode
> > Sampling and Outputs:
> >   Avg freq      580000 KHz
> >   Avg freq      580000 KHz
> >   Avg freq      580000 KHz
> > Setting CPU in performance mode
> > Sampling and Outputs:
> >   Avg freq      4640000 KHz
> >   Avg freq      4220000 KHz
> >   Avg freq      4640000 KHz
> >
> > Penny Zheng (18):
> >   xen/cpufreq: guard perf.states[] access with XEN_PX_INIT
> >   xen/cpufreq: move "init" flag into common structure
> >   xen/cpufreq: extract _PSD info from "struct xen_processor_performance"
> >   xen/cpufreq: introduce new sub-hypercall to propagate CPPC data
> >   xen/cpufreq: refactor cmdline "cpufreq=xxx"
> >   xen/cpufreq: introduce "cpufreq=amd-cppc" xen cmdline
> >   xen/cpufreq: disable px statistic info in amd-cppc mode
> >   xen/cpu: Expand core frequency calculation for AMD Family 1Ah CPUs
> >   xen/amd: introduce amd_process_freq() to get processor frequency
> >   xen/cpufreq: introduce a new amd cppc driver for cpufreq scaling
> >   xen/cpufreq: implement EPP support for the amd-cppc driver in active
> >     mode
> >   xen/cpufreq: get performance policy from governor set via xenpm
> >   xen/cpufreq: normalize hwp driver check with hwp_active()
> >   xen/cpufreq: introduce GET_CPUFREQ_CPPC sub-cmd
> >   xen/cpufreq: bypass governor-related para for amd-cppc-epp
> >   tools: drop "has_num" condition check for cppc mode
> >   tools: optimize cpufreq average freq print
> >   xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-
> cppc
> >     driver
>
> As indicated in individual replies, three of the patches may be possible to 
> go in
> before you re-post. Subject to what I said in the replies (patches 02, 08, 
> and 13).
> Please clarify what (if anything) to do.
>

For patch 02, the only concern is that it is based on 01, and 01 shall be 
removed and I'll add extra check for CPPC to ensure ->perf.state_count must be 
zero in get_cpufreq_para()
For patch 08, I already have agreed in individual reply
For patch 13, ok for me too

> Jan