[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <95b31cafb584c055bf303dc79ed7c389538d29c5.camel@linux.intel.com>
Date: Tue, 01 Oct 2024 07:46:40 -0700
From: srinivas pandruvada <srinivas.pandruvada@...ux.intel.com>
To: Christian Loehle <christian.loehle@....com>, "Rafael J. Wysocki"
<rafael@...nel.org>
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
peterz@...radead.org, juri.lelli@...hat.com, mingo@...hat.com,
dietmar.eggemann@....com, vschneid@...hat.com, vincent.guittot@...aro.org,
Johannes.Thumshirn@....com, adrian.hunter@...el.com,
ulf.hansson@...aro.org, bvanassche@....org, andres@...razel.de,
asml.silence@...il.com, linux-block@...r.kernel.org,
io-uring@...r.kernel.org, qyousef@...alina.io, dsmythies@...us.net,
axboe@...nel.dk
Subject: Re: [RFC PATCH 6/8] cpufreq: intel_pstate: Remove iowait boost
Hi Christian,
On Tue, 2024-10-01 at 10:57 +0100, Christian Loehle wrote:
> On 9/30/24 21:35, srinivas pandruvada wrote:
> > On Mon, 2024-09-30 at 20:03 +0200, Rafael J. Wysocki wrote:
> > > +Srinivas who can say more about the reasons why iowait boosting
> > > makes
> > > a difference for intel_pstate than I do.
> > >
>
> Hi Srinivas,
>
> > It makes difference on Xeons and also GFX performance.
>
> AFAIU the GFX performance with iowait boost is a regression though,
> because it cuts into the system power budget (CPU+GPU), especially
> on desktop and mobile chips (but also some servers), no?
> https://lore.kernel.org/lkml/20180730220029.81983-1-srinivas.pandruvada@linux.intel.com/
> https://lore.kernel.org/lkml/e7388bf4-deb1-34b6-97d7-89ced8e78ef1@intel.com/
> Or is there a reported case where iowait boosting helps
> graphics workloads?
>
GFX is complex as you have both cases depending on the generation. We
don't enable the control by default. There is a user space control, so
that it can be selected when it helps.
> > The actual gains will be model specific as it will be dependent on
> > hardware algorithms and EPP.
> >
> > It was introduced to solve regression in Skylake xeons. But even in
> > the
> > recent servers there are gains.
> > Refer to
> > https://lkml.iu.edu/hypermail/linux/kernel/1806.0/03574.html
>
> Did you look into PELT utilization values at that time?
No. But boost is needed for idle or semi-idle CPUs, otherwise HWP would
have already running at higher frequency. But we could avoid boot if
util is above a threshold.
> I see why intel_pstate might be worse off than schedutil wrt removing
> iowait boosting and do see two remedies essentially:
> 1. Boost after all sleeps (less aggressively), although I'm not a
> huge fan of
> this.
> 2. If the gap between util_est and HWP-determined frequency is too
> large
> then apply some boost. A sort of fallback on a schedutil strategy.
> That would of course require util_est to be significantly large in
> those
> scenarios.
>
> I might try to propose something for 2, although as you can probably
> guess, playing with HWP is somewhat uncharted waters for me.
>
Now we sample the last HWP determined frequency at every tick and can
use to avoid boost. So need some experiments.
> Since intel_pstate will actually boost into unsustainable P-states,
> there should be workloads that regress with iowait boosting. I'll
> go looking for those.
Xeons power limit is in order of 100s of Watts. So boost doesn't
generally to unsustainable state. Even if all cores boost at the same
time, the worst case we still get all core turbo.
Thanks,
Srinivas
>
>
Powered by blists - more mailing lists