Messages in this thread | | | Date | Thu, 13 Feb 2020 14:20:24 +0100 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH v4 0/6] sched/cpufreq: Make schedutil energy aware |
| |
On Thu, Feb 13, 2020 at 11:55:32AM +0000, Douglas Raillard wrote: > On 2/10/20 1:30 PM, Peter Zijlstra wrote:
> > So ARM64 will soon get x86-like power management if I read these here > > patches right: > > > > https://lkml.kernel.org/r/20191218182607.21607-2-ionela.voinescu@arm.com > > > > And I'm thinking a part of Rafael's concerns will also apply to those > > platforms. > > AFAIU there is an important difference: ARM64 firmware should not end up > increasing frequency on its own, it should only cap the frequency. That > means that the situation stays the same for that boost: > > Let's say you let schedutil selecting a freq that is +2% more power > hungry. That will probably not be enough to make it jump to the next > OPP, so you end up not boosting. Now if there is a firmware that decides > for some reasons to cap frequency, it will be a similar situation.
The moment you give out OPP selection to a 3rd party (be it firmware or a micro-controller) things are uncertain at best anyway.
Still, in general, if you give it higher input, it tends to at least consider going faster -- which might be all you can ask for...
So I'm not exactly seeing what your argument is here.
> > Right, so the condition 'util_avg > util_est' makes sense to trigger > > some sort of boost off of. > > > > What kind would make sense for these platforms? One possibility would be > > to instead of frobbing the energy margin, as you do here, to frob the C > > in get_next_freq(). > > If I'm correct, changing the C value would be somewhat similar to the > relative boosting I had in a previous version. Maybe adding a fixed > offset would give more predictable results as was discussed with Vincent > Guittot. In any case, it would change the perceived util (like iowait > boost).
It depends a bit on what you change C into. If we do something trivial like: 1.25 ; !(util_avg > util_est) C := { 2 ; (util_avg > util_est)
ie. a binary selection of constants, then yes, I suppose that is the case.
But nothing stops us from making it more complicated; or having it depend on the presence of EM data.
> > (I have vague memories of this being proposed earlier; it also avoids > > that double OPP iteration thing complained about elsewhere in this > > thread if I'm not mistaken). > > It should be possible to get rid of the double iteration mentioned by > Quentin. Choosing to boost the util or the energy boils down to: > > 1) If you care more about predictable battery life (or energy bill) than > predictability of the boost feature, EM should be used. > > 2) If you don't have an EM or you care more about having a predictable > boost for a given workload, use util (or disable that boost). > > The rational is that with 1), you will get a different speed boost for a > given workload depending on the other things executing at the same time, > as the speed up is not linear with the task-related metric (util - > util_est). If you are already at high freq because of another workload, > the speed up will be small because the next 100Mhz will cost much more > than the same +100Mhz delta starting from a low OPP.
It's just that I'm not seeing how 1 actually works or provides that more predictable battery life I suppose. We have this other sub-thread to argue about that :-)
> > That is; I'm thinking it is important (esp. now that we got frequency > > invariance sorted for x86), to have this patch also work for !EM > > architectures (as those ARM64-AMU things would be). > > For sure, that feature is supposed to help in cases that would be > impossible to pinpoint with hardware, since it has to know what tasks > execute.
OK, so I'm thinking we're agreeing that it would be good to have this support !EM systems too.
| |