On Thu, Oct 17, 2019 at 03:23:04PM +0100, Douglas Raillard wrote: > On 10/17/19 10:50 AM, Peter Zijlstra wrote: > > Now, the thing is, we use map_util_freq() in more places, and should we > > not reflect this increase in C for all of them? That is, why is this > > patch changing get_next_freq() and not map_util_freq(). > > > > I don't think that question is answered in the Changelogs. > > > > Exactly because it does change the energy consumption (it must) should > > that not also be reflected in the EAS logic? > > map_util_freq() is only used in schedutil and in EAS by compute_energy(), so > I retarget the question at compute_energy(). It is supposed to compute > the energy consumed by a given CPU if a given task was migrated on it. > This implies some assumptions on util signals: > 1) util(_est.enqueued) of the task is representative of the task's > duty cycle (the semantic of util is somehow blurry for aperiodic tasks > AFAIK). > 2) util of the task is CPU-invariant
( we know this to be false, but do indeed make this assumption because simplicity, taking IPC differences into account would just complicate things more ) > 3) task util + target CPU util = new target CPU util for the > foreseeable future, i.e. the amount of future we can predict with > reasonable accuracy. Otherwise we would end up moving things around > all the time. > > Since ramp boost is designed to be transient, integrating it > (indirectly) in "target CPU util" will add some noise to the placement > decision, potentially rendering it obsolete as soon as the boosting > stops. Basing a costly decision on that does not sound like a good > idea IMHO. Well, we _hope_ recent past is a reasonable predictor for the near future. We of course know it'll be complete crap every so often, but hope that on average it is true more than false :-) Anyway, the above seems like a sensible enough argument, and seems worthy of being part of the Changelog. Also maybe a comment in schedutil as to why there is a map_util_freq() modifier there.
