On 30/03/17 22:13, Rafael J. Wysocki wrote:

On Thu, Mar 30, 2017 at 10:58 AM, Juri Lelli [off-list ref] wrote:

quoted

Hi,

Hi,

quoted

On 30/03/17 00:41, Rafael J. Wysocki wrote:

quoted

On Friday, March 24, 2017 02:08:59 PM Juri Lelli wrote:

quoted

No assumption can be made upon the rate at which frequency updates get
triggered, as there are scheduling policies (like SCHED_DEADLINE) which
don't trigger them so frequently.

Remove such assumption from the code.

But the util/max values for idle CPUs may be stale, no?

Right, that might be a problem. A proper solution I think would be to
remotely update such values for idle CPUs, and I believe Vincent is
working on a patch for that.

As mid-term workarounds, changing a bit the current one, come to my
mind:

 - consider TICK_NSEC (continue) only when SCHED_CPUFREQ_DL is not set
 - remove CFS contribution (without triggering a freq update) when a CPU
   enters IDLE; this might not work well, though, as we probably want
   to keep in blocked util contribution for a bit

What you think is the way to go?

Well, do we want SCHED_DEADLINE util contribution to be there even for
idle CPUs?

DEADLINE util contribution is removed, even if the CPU is idle, by the
reclaiming mechanism when we know (applying GRUB algorithm rules [1])
that it can't be used anymore by a task (roughly speaking). So, we
shouldn't have this problem in the DEADLINE case.

[1] https://marc.info/?l=linux-kernel&m=149029880524038