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
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
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 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 :)