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

[Patrick Bellasi <patrick.bellasi@arm.com>]

On 02-Mar 17:09, Vincent Guittot wrote:
> On 2 March 2017 at 16:45, Patrick Bellasi <patrick.bellasi@arm.com> wrote:
> > The current version of schedutil has some issues related to the management
> > of update flags used by systems with frequency domains spawning multiple CPUs.
> >
> > Each time a CPU utilisation update is issued by the scheduler a set of flags
> > are configured to define (mainly) which class is asking for a utilisation
> > update. These flags are then used by the frequency selection policy to
> > identify the OPP to choose.
> >
> > In the current implementation, CPU flags are overridden each time the
> > scheduler calls schedutil for an update. Such a behaviour produces issues
> > in these scenarios, where we assume CPU1 and CPU2 share the same frequency
> > domain:
> > a) a RT task which executed on CPU1 can keep the domain at an high frequency
> >    for a long period of time, even if there are no longer RT tasks on
> >    CPUs in that domain
> 
> Normally this is dropped after a tick.
> Nevertheless, there is an issue if the freq_update_delay_ns is shorter
> than a tick because of sugov RT thread

Indeed, I've noticed that a small FAIR task running on CPU2 is quite
likely to be running at an higher OPP just because on the other CPU of
the same frequency domain (i.e. CPU1) sometimes we have the sugov RT
thread running.

In this case, the RT flag in CPU1 is never cleared when that core is
always idle but for the execution of the sugov thread.

-- 
#include <best/regards.h>

Patrick Bellasi