Re: [RFC PATCH 6/8] cpufreq: intel_pstate: Remove iowait boost

[Christian Loehle]

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@xxxxxxxxxxxxxxx/
https://lore.kernel.org/lkml/e7388bf4-deb1-34b6-97d7-89ced8e78ef1@xxxxxxxxx/
Or is there a reported case where iowait boosting helps
graphics workloads?

> 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?
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.

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.