Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

From: Viresh Kumar
Date: Wed Dec 20 2017 - 03:49:12 EST

On 20-12-17, 09:31, Peter Zijlstra wrote:
> On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote:

> Please use the normal link format:
> Then I can find them without having to resort to a frigging browser
> thing.

Sure, and that would be much easier for me as well as that's how I got
to those links. Here they are again ..

> I'll try and dig through the email I have.


> > Well that also looks fine to me, and that would mean this:
> >
> > - We remove SCHED_CPUFREQ_RT and SCHED_CPUFREQ_DL flags, but still
> > call the utilization callbacks from RT and DL classes.
> Didn't juri have patches to make DL do something sane? But yes, I think
> those flags are part of the problem.

Sure, DL will be more like CFS going forward. I was just commenting
based on what we have upstream today.

> > - From the utilization handler, we check runqueues of all three sched
> > classes to see if they have some work pending (this can be done
> > smartly by checking only RT first and skipping other checks if RT
> > has some work).
> No that's wrong. DL should provide a minimum required based on existing
> reservations, we can add the expected CFS average on top and request
> that.

Right, that should be the case after Juri's patches.

> And for RT all we need to know is if current is of that class, otherwise
> we don't care.

What about this case: A CFS task is running currently and an RT task
is enqueued.

- Is it always the case that the CFS task is preempted immediately and
the CPU is given to RT task ? I was talking to Vincent earlier and
he told me that for certain configurations the CFS task may keep
running until the next tick.

- What if the CFS task has disabled preemption ?

- More corner cases like this ?

Above cases may not let schedutil to raise frequency to MAX even when
we have RT stuff enqueued. And that's why I tried to track all sched
classes for which we have work enqueued for. There are great chances
that my understanding here is wrong though :)