On Monday 30 Sep 2024 at 18:34:24 (+0200), Rafael J. Wysocki wrote:
> On Thu, Sep 5, 2024 at 11:27 AM Christian Loehle
> <christian.loehle@xxxxxxx> wrote:
> >
> > iowait boost in schedutil was introduced by
> > commit ("21ca6d2c52f8 cpufreq: schedutil: Add iowait boosting").
> > with it more or less following intel_pstate's approach to increase
> > frequency after an iowait wakeup.
> > Behaviour that is piggy-backed onto iowait boost is problematic
> > due to a lot of reasons, so remove it.
> >
> > For schedutil specifically these are some of the reasons:
> > 1. Boosting is applied even in scenarios where it doesn't improve
> > throughput.
>
> Well, I wouldn't argue this way because it is kind of like saying that
> air conditioning is used even when it doesn't really help. It is
> sometimes hard to know in advance whether or not it will help though.
>
> > 2. The boost is not accounted for in EAS: a) feec() will only consider
> > the actual task utilization for task placement, but another CPU might
> > be more energy-efficient at that capacity than the boosted one.)
> > b) When placing a non-IO task while a CPU is boosted compute_energy()
> > assumes a lower OPP than what is actually applied. This leads to
> > wrong EAS decisions.
>
> That's a very good point IMV and so is the one regarding UCLAMP_MAX (8
> in your list).
I would actually argue that this is also an implementation problem
rather than something fundamental about boosting. EAS could be taught
about iowait boosting and factor that into the decisions.
> If the goal is to set the adequate performance for a given utilization
> level (either actual or prescribed), boosting doesn't really play well
> with this and it shouldn't be used at least in these cases.
There's plenty of cases where EAS will correctly understand that
migrating a task away will not reduce the OPP (e.g. another task on the
rq has a uclamp_min request, or another CPU in the perf domain has a
higher request), so iowait boosting could probably be added.
In fact if the iowait boost was made a task property, EAS could easily
understand the effect of migrating that boost with the task (it's not
fundamentally different from migrating a task with a high uclamp_min
from the energy model perspective).
> > 3. Actual IO heavy workloads are hardly distinguished from infrequent
> > in_iowait wakeups.
>
> Do infrequent in_iowait wakeups really cause the boosting to be
> applied at full swing?
>
> > 4. The boost isn't accounted for in task placement.
>
> I'm not sure what exactly this means. "Big" vs "little" or something else?
>
> > 5. The boost isn't associated with a task, it therefore lingers on the
> > rq even after the responsible task has migrated / stopped.
>
> Fair enough, but this is rather a problem with the implementation of
> boosting and not with the basic idea of it.
+1
> > 6. The boost isn't associated with a task, it therefore needs to ramp
> > up again when migrated.
>
> Well, that again is somewhat implementation-related IMV, and it need
> not be problematic in principle. Namely, if a task migrates and it is
> not the only one in the "new" CPUs runqueue, and the other tasks in
> there don't use in_iowait, maybe it's better to not boost it?
>
> It also means that boosting is not very consistent, though, which is a
> valid point.
>
> > 7. Since schedutil doesn't know which task is getting woken up,
> > multiple unrelated in_iowait tasks lead to boosting.
>
> Well, that's by design: it boosts, when "there is enough IO pressure
> in the runqueue", so to speak.
>
> Basically, it is a departure from the "make performance follow
> utilization" general idea and it is based on the observation that in
> some cases performance can be improved by taking additional
> information into account.
>
> It is also about pure performance, not about energy efficiency.
>
> > 8. Boosting is hard to control with UCLAMP_MAX (which is only active
> > when the task is on the rq, which for boosted tasks is usually not
> > the case for most of the time).
Sounds like another reason to make iowait boosting per-task to me :-)
I've always thought that turning iowait boosting into some sort of
in-kernel uclamp_min request would be a good approach for most of the
issues mentioned above. Note that I'm not necessarily saying to use the
actual uclamp infrastructure (though it's valid option), I'm really just
talking about the concept. Is that something you've considered?
I presume we could even factor out the 'logic' part of the code that
decides out to request the boost into its own thing, and possibly have
different policies for different use-cases, but that might be overkill.
Thanks,
Quentin
