[Public] > -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: Tuesday, June 17, 2025 6:42 PM > To: Penny, Zheng <penny.zh...@amd.com> > Cc: Huang, Ray <ray.hu...@amd.com>; Andrew Cooper > <andrew.coop...@citrix.com>; Roger Pau Monné <roger....@citrix.com>; > Anthony PERARD <anthony.per...@vates.tech>; Orzel, Michal > <michal.or...@amd.com>; Julien Grall <jul...@xen.org>; Stefano Stabellini > <sstabell...@kernel.org>; Juergen Gross <jgr...@suse.com>; xen- > de...@lists.xenproject.org > 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
