From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Tero Kristo <tero.kristo@linux.intel.com>,
Hans de Goede <hdegoede@redhat.com>
Cc: srinivas.pandruvada@linux.intel.com,
platform-driver-x86@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] Documentation: admin-guide: pm: Add efficiency vs. latency tradeoff to uncore documentation
Date: Fri, 30 Aug 2024 13:12:44 +0300 (EEST) [thread overview]
Message-ID: <858a908e-8218-3925-ea06-f3da256110e9@linux.intel.com> (raw)
In-Reply-To: <71e6475c99e193c4ae6e5d45b72b528cdf5f3f62.camel@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3621 bytes --]
On Fri, 30 Aug 2024, Tero Kristo wrote:
> 1. On Thu, 2024-08-29 at 14:39 +0300, Tero Kristo wrote:
> > On Thu, 2024-08-29 at 12:18 +0300, Ilpo Järvinen wrote:
> > > On Wed, 28 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>
> > > > ---
> > > > v2:
> > > > * Largely re-wrote the documentation
> > > >
> > > > .../pm/intel_uncore_frequency_scaling.rst | 59
> > > > +++++++++++++++++++
> > > > 1 file changed, 59 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..26ded32b06f5 100644
> > > > --- a/Documentation/admin-
> > > > guide/pm/intel_uncore_frequency_scaling.rst
> > > > +++ b/Documentation/admin-
> > > > guide/pm/intel_uncore_frequency_scaling.rst
> > > > @@ -113,3 +113,62 @@ 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
> > > > +-------------------------------
> > > > +
> > > > +The Efficiency Latency Control (ELC) feature improves
> > > > performance
> > > > +per watt. With this feature hardware power management algorithms
> > > > +optimize trade-off between latency and power consumption. For
> > > > some
> > > > +latency sensitive workloads further tuning can be done by SW to
> > > > +get desired performance.
> > > > +
> > > > +The hardware monitors the average CPU utilization across all
> > > > cores
> > > > +in a power domain at regular intervals and decides an 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
> > > > SW.
> > > > +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
> > >
> > > Consider the following simplification:
> > >
> > > "the user defined uncore frequency floor frequency" ->
> > > "the user-defined uncore floor frequency"
> > >
> > > I think it tells the same even without that first "frequency".
> > >
> > > Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > >
> >
> > Yeah, it looks kind of silly. I think that's just a typo from my
> > side,
> > thanks for catching.
>
> Do you want me to send a new version of this patch or do you fix it
> locally? Rest of the patches don't seem to need any changes atm.
That's up to Hans but that looks trivial change so probably he can fix
that while applying.
Hans, v2 of this series seems ready to go (with the small change into
the documentation patch as discussed above).
--
i.
next prev parent reply other threads:[~2024-08-30 10:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-28 15:34 [PATCH v2 0/3] Intel uncore driver ELC support Tero Kristo
2024-08-28 15:34 ` [PATCH v2 1/3] Documentation: admin-guide: pm: Add efficiency vs. latency tradeoff to uncore documentation Tero Kristo
2024-08-29 9:18 ` Ilpo Järvinen
2024-08-29 11:39 ` Tero Kristo
2024-08-30 7:23 ` Tero Kristo
2024-08-30 10:12 ` Ilpo Järvinen [this message]
2024-09-04 17:51 ` Hans de Goede
2024-08-28 15:34 ` [PATCH v2 2/3] platform/x86/intel-uncore-freq: Add support for efficiency latency control Tero Kristo
2024-08-29 9:14 ` Ilpo Järvinen
2024-08-30 7:21 ` Tero Kristo
2024-08-30 10:09 ` Ilpo Järvinen
2024-08-28 15:34 ` [PATCH v2 3/3] platform/x86/intel-uncore-freq: Add efficiency latency control to sysfs interface Tero Kristo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=858a908e-8218-3925-ea06-f3da256110e9@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tero.kristo@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®