Re: [PATCH v2 0/6] cpufreq: schedutil: fixes for flags updates

From: Rafael J. Wysocki
Date: Thu Jul 06 2017 - 18:34:03 EST

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.