Messages in this thread | | | Date | Thu, 10 Jun 2021 16:28:57 +0100 | From | Qais Yousef <> | Subject | Re: iowait boost is broken |
| |
On 06/09/21 09:50, Quentin Perret wrote: > On Tuesday 08 Jun 2021 at 19:46:54 (+0200), Peter Zijlstra wrote: > > On Mon, Jun 07, 2021 at 08:10:32PM +0100, Beata Michalska wrote: > > > So back to the expectations. > > > The main problem, as I see it, is what do we actually want to achieve with > > > the I/O boosting? Is it supposed to compensate the time lost while waiting > > > for the I/O request to be completed or is is supposed to optimize the rate > > > at which I/O requests are being made. > > > > The latter, you want to increase the race of submission. > > > > > Do we want to boost I/O bound tasks by > > > default, no limits applied or should we care about balancing performance > > > vs power ? And unless those expectations are clearly stated, we might not > > > get too far with any changes, really. > > > > You want to not increase power beyond what is needed to match the rate > > of processing I suppose. > > Note that in some cases we also don't care about throughput, and would > prefer to keep the frequency for some unimportant IO bound tasks (e.g. > background logging deamons and such). Uclamp.max indicates this to some > extent.
In theory, one can have a user space daemon that monitors IO (via BPF?) and auto boost via uclamp. You can have allow/disallow list per-app too to setup the limits.
So I say rm -rf iowait_boost and let's make it a user space problem :)
/me runs
-- Qais Yousef
| |