Skip to content

Commit 8022ae2

Browse files
Tero Kristojwrdegoede
authored andcommitted
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>
1 parent d9dca21 commit 8022ae2

File tree

1 file changed

+59
-0
lines changed

1 file changed

+59
-0
lines changed

Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -113,3 +113,62 @@ to apply at each uncore* level.
113113

114114
Support for "current_freq_khz" is available only at each fabric cluster
115115
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

0 commit comments

Comments
 (0)