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.
