Thread (42 messages) 42 messages, 7 authors, 2017-12-20

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

From: Peter Zijlstra <peterz@infradead.org>
Date: 2017-12-20 08:31:37
Also in: lkml

On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote:
On 19-12-17, 20:25, Peter Zijlstra wrote:
quoted
Yeah, not happy about this either; we had code that did the right thing
without this extra tracking I think.
Sure, but how do you suggest we fix the problems we are facing with
the current design? Patrick had a completely different proposal for
solving those problems, which I didn't like very much. This patchset
replaced these patches from Patrick:
Please use the normal link format:

  https://lkml.kernel.org/r/$MSGID

Then I can find them without having to resort to a frigging browser
thing.

I'll try and dig through the email I have.
quoted
Also, we can look at the rq state if we want to, we don't need to
duplicate that state.
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.
- 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.

And for RT all we need to know is if current is of that class, otherwise
we don't care.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help