Re: [PATCH 1/3] Documentation: admin-guide: pm: Add efficiency vs. latency tradeoff to uncore documentation

[srinivas pandruvada <srinivas.pandruvada@linux.intel.com>]

On Fri, 2024-08-23 at 15:28 +0300, Ilpo Järvinen wrote:
> On Wed, 21 Aug 2024, Tero Kristo wrote:
> 
> > 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>
> > ---
> >  .../pm/intel_uncore_frequency_scaling.rst     | 51
> > +++++++++++++++++++
> >  1 file changed, 51 insertions(+)
> > 
> > diff --git a/Documentation/admin-
> > guide/pm/intel_uncore_frequency_scaling.rst b/Documentation/admin-
> > guide/pm/intel_uncore_frequency_scaling.rst
> > index 5ab3440e6cee..fb83aa2b744e 100644
> > --- a/Documentation/admin-
> > guide/pm/intel_uncore_frequency_scaling.rst
> > +++ b/Documentation/admin-
> > guide/pm/intel_uncore_frequency_scaling.rst
> > @@ -113,3 +113,54 @@ to apply at each uncore* level.
> >  
> >  Support for "current_freq_khz" is available only at each fabric
> > cluster
> >  level (i.e., in uncore* directory).
> > +
> > +Efficiency vs. Latency Tradeoff
> 
> Does this section even cover the "tradeoff" part in its body? Why not
> call 
> it directly "Control" after ELC?
> 
> > +-------------------------------
> > +
> > +In the realm of high-performance computing, particularly with Xeon
> > +processors, managing uncore frequency is an important aspect of
> > system
> > +optimization. Traditionally, the uncore frequency is ramped up
> > rapidly
> > +in high load scenarios. While this strategy achieves low latency,
> > which
> > +is crucial for time-sensitive computations, it does not
> > necessarily yield
> > +the best performance per watt, —a key metric for energy efficiency
> > and
> > +operational cost savings.
> 
> This entire paragraph feels more prose or history book than
> documentation 
> text. I'd suggest using something that goes more directly into the
> point
> about what ELC brings to the table (I suppose the goal is
> "performance 
> per watt" optimization, even that goal is only implied by the current
> text, not explicitly stated as the goal here).
> 

What about this?

Traditionally, the uncore frequency is ramped up to reach the maximum 
possible level based on parameters like EPB (Energy perf Bias) and
other system power management settings programmed by BIOS.  While this
strategy achieves low latency for latency sensitive applications, it
does not necessarily yield the best performance per watt. 

The Efficiency Latency Control (ELC) feature is added to improve
performance per watt. With this feature hardware power management
algorithms optimize trade-off between latency and power consumption.
But for some latency sensitive workloads further tuning can be done
from OS to get desired performance.

The hardware monitors the average CPU utilization across all cores
in a power domain at regular intervals and decides a uncore frequency. 
While this may result in the best performance per watt, workload may be
expecting higher performance at the expense of power. Consider an
application that intermittently wakes up to perform memory reads on an
otherwise idle system. In such cases, if hardware lowers uncore
frequency, then there may be delay in ramp up of frequency to meet
target performance. 

The ELC control defines some parameters which can be changed from OS.
If the average CPU utilization is below a user defined threshold
(elc_low_threshold_percent attribute below), the user defined uncore
frequency floor frequency will be used (elc_floor_freq_khz attribute 
below) instead of hardware calculated minimum. 

Similarly in high load scenario where the CPU utilization goes above 
the high threshold value (elc_high_threshold_percent attribute below) 
instead of jumping to maximum uncore frequency, uncore frequency is 
increased in 100MHz steps until the power limit is reached.

Attributes for efficiency latency control: 
.. 
.. 

Thanks,
Srinivas