https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292615
--- Comment #29 from Olivier Certner <[email protected]> --- (In reply to ShengYi Hung from comment #22) > Sorry for the late reply since I am a career soldier currently... I heard that this was temporary and hope you'll return soon. > Cy's case is easier to solve. We can read the Lowest Frequency and Nominal > Frequency in ACPI _CPC object then do interpolation for other Frequency (High > and Guaranteed). When getting all of the frequency and cppc value, we can > make cpufreq mutable and allow to powerd(8) to modify the value in both amd's > and intel's case. I have a WIP generic CPPC (fully relies on the _CPC object) > driver which can be used in aarch64 and amd64 platforms but some ACPI > features are missing in FreeBSD. I am still working on this. I don't think we can actually allow to modify the current frequency with good effect, and even if we could hack something that feels like a dead end. The frequency as currently reported by 'hwpstate_amd' in CPPC mode is an estimate based on a delay loop. Moreover, even if AMD's APM states there is a direct mapping between the performance values and the actual CPU frequencies (which varies among their processors), it is unclear if we can derive it with confidence, and even if we can, how are we going to use the performance level a given frequency would map to? We could naturally use it as the desired performance value, but then the hardware only takes that value as a hint, whether we are in autonomous mode or not, and we don't know how much it can deviate from the desired value. Other values having influence are the minimum and maximum performance, so if we exactly want a given frequency, we can probably set these to the mapped performance value, in addition to the desired value (if we ought to believe the ACPI spec), but then that completely defeats the purpose of CPPC, basically turning it into regular P-states. At this point, it seems better to just deactivate CPPC than to activate it. Additionally, I don't think there is any guarantee that this frequency <-> perf level mapping will continue to exist in future AMD processors. And I don't think such a mapping necessarily exists for Intel processors (we should strive to be consistent in the controls/reports we provide). As CPPC is standardized by ACPI, I think we should rather amend cpufreq(4) to support CPPC controls and then teach powerd(8) about them, when CPPC's autonomous mode is not used. When CPPC's autonomous mode is on, it's likely that we won't need powerd(8) at all. What could probably solve Cy's case is the ability to tweak the maximum performance level. As a next step, I'll see to add such a control knob. It's true that there should be, according to the APM, on AMD processors. However, allowing to set it is basically incompatible with . EPP value and the actual CPU frequency is said to , given that I doubt that we should allow the frequency to be changed. doubt that allowing to set a frequency among those reported by 'hwpstate_amd'. Since Efficiency/Performance Preference frameworks, both for Intel and AMD -- You are receiving this mail because: You are the assignee for the bug.
