tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Documentation: admin-guide: pm: Add efficiency vs. latency tradeoff to uncore documentation

Added documentation about the functionality of efficiency vs. latency tradeoff
control in intel Xeon processors, and how this is configured via sysfs.

Signed-off-by: Tero Kristo <tero.kristo@linux.intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240828153657.1296410-2-tero.kristo@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

authored by

Tero Kristo and committed by
Hans de Goede 8022ae2c d9dca215

+59
+59
Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst
··· 113 113 114 114 Support for "current_freq_khz" is available only at each fabric cluster 115 115 level (i.e., in uncore* directory). 116 + 117 + Efficiency vs. Latency Tradeoff 118 + ------------------------------- 119 + 120 + The Efficiency Latency Control (ELC) feature improves performance 121 + per watt. With this feature hardware power management algorithms 122 + optimize trade-off between latency and power consumption. For some 123 + latency sensitive workloads further tuning can be done by SW to 124 + get desired performance. 125 + 126 + The hardware monitors the average CPU utilization across all cores 127 + in a power domain at regular intervals and decides an uncore frequency. 128 + While this may result in the best performance per watt, workload may be 129 + expecting higher performance at the expense of power. Consider an 130 + application that intermittently wakes up to perform memory reads on an 131 + otherwise idle system. In such cases, if hardware lowers uncore 132 + frequency, then there may be delay in ramp up of frequency to meet 133 + target performance. 134 + 135 + The ELC control defines some parameters which can be changed from SW. 136 + If the average CPU utilization is below a user-defined threshold 137 + (elc_low_threshold_percent attribute below), the user-defined uncore 138 + floor frequency will be used (elc_floor_freq_khz attribute below) 139 + instead of hardware calculated minimum. 140 + 141 + Similarly in high load scenario where the CPU utilization goes above 142 + the high threshold value (elc_high_threshold_percent attribute below) 143 + instead of jumping to maximum uncore frequency, frequency is increased 144 + in 100MHz steps. This avoids consuming unnecessarily high power 145 + immediately with CPU utilization spikes. 146 + 147 + Attributes for efficiency latency control: 148 + 149 + ``elc_floor_freq_khz`` 150 + This attribute is used to get/set the efficiency latency floor frequency. 151 + If this variable is lower than the 'min_freq_khz', it is ignored by 152 + the firmware. 153 + 154 + ``elc_low_threshold_percent`` 155 + This attribute is used to get/set the efficiency latency control low 156 + threshold. This attribute is in percentages of CPU utilization. 157 + 158 + ``elc_high_threshold_percent`` 159 + This attribute is used to get/set the efficiency latency control high 160 + threshold. This attribute is in percentages of CPU utilization. 161 + 162 + ``elc_high_threshold_enable`` 163 + This attribute is used to enable/disable the efficiency latency control 164 + high threshold. Write '1' to enable, '0' to disable. 165 + 166 + Example system configuration below, which does following: 167 + * when CPU utilization is less than 10%: sets uncore frequency to 800MHz 168 + * when CPU utilization is higher than 95%: increases uncore frequency in 169 + 100MHz steps, until power limit is reached 170 + 171 + elc_floor_freq_khz:800000 172 + elc_high_threshold_percent:95 173 + elc_high_threshold_enable:1 174 + elc_low_threshold_percent:10