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

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

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