On Tuesday, July 04, 2017 06:34:05 PM Patrick Bellasi wrote: > Each time a CPU utilisation update is issued by the scheduler a flag, which > mainly defines which scheduling class is asking for the update, is used by the > frequency selection policy to support the selection of the most appropriate > OPP. > > In the current implementation, CPU flags are overridden each time the > scheduler > calls schedutil for an update. Such a behavior seems to be sub-optimal, > especially on systems where frequency domains span across multiple CPUs. > > Indeed, assuming CPU1 and CPU2 share the same frequency domain, there can be > the following issues: > > A) Small FAIR task running at MAX OPP. > A RT task, which just executed on CPU1, can keep the domain at the > max frequency for a prolonged period of time after its completion, > even if there are no longer RT tasks running on CPUs of its domain. > > B) FAIR wakeup reducing the OPP of the current RT task. > A FAIR task enqueued in a CPU where a RT task is running overrides the > flag > configured by the RT task thus potentially causing an unwanted frequency > drop. > > C) RT wakeup not running at max OPP. > An RT task waking up on a CPU which has recently updated its OPP can > be forced to run at a lower frequency because of the throttling > enforced by schedutil, even if there are not OPP transitions > currently in progress. > > .:: Patches organization > ======================== > > This series proposes a set of fixes for the aforementioned issues and it's an > update addressing all the main comments collected from the previous posting > [1].
It seems to me that there is a nonzero overlap between this and the Juri's work. If that's correct, I'd like this series to go on top of the Juri's one. Thanks, Rafael
