On 31/08/16 18:40, Peter Zijlstra wrote:

On Wed, Aug 31, 2016 at 06:28:10PM +0200, Thomas Gleixner wrote:

quoted

quoted

That is the way it's been with cpufreq and many systems (including all
mobile devices) rely on that to not destroy power. RT + variable cpufreq
is not deterministic.

Given we don't have good constraints on RT tasks I don't think we should
try to strengthen the semantics there. Folks should either move to DL if
they want determinism *and* not-sucky power, or continue disabling
cpufreq if they are able to do so.

RT deterministic behaviour is all about meeting the deadlines. If your
deadline is relaxed enough that you can meet it even with the lowest cpu
frequency then it's perfectly fine to enable cpufreq. The same logic applies
to C-States.

There are a lot of RT systems out there which enable both. If cpufreq or
c-states cause a deadline violation because the constraints of the system are
tight, then people will disable it and we need a knob for both.

Realtime is not as fast as possible. It's as fast as specified.

Sure, problem is of course that RR/FIFO doesn't specify anything so the
users are left to prod knobs.

Another problem is that we have many semi related knobs; we have the
global RT runtime limit knob, but that doesn't affect cpufreq (maybe it
should)

Maybe we could create this sort of link when using the cgroup RT
throttling interface as well? It should still then fit well once we
replace the underlying mechanism with DL reservations. And, AFAIK, the
interface is used by Android folks already.

and cpufreq has knobs to set f_min and f_max, which again are
unaware of RT anything.

So before we go do anything, I'd like input on what is needed and how
things should tie together to make most sense.