Re: [PATCH 2/2] sched: cpufreq: use rt_avg as estimate of required RT CPU capacity

[Thomas Gleixner]

On Fri, 2 Sep 2016, Juri Lelli wrote:
> On 01/09/16 14:48, Steve Muckle wrote:
> > On Wed, Aug 31, 2016 at 06:00:02PM +0100, Juri Lelli wrote:
> > > > 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.
> > 
> > I'm not sure how the upper bounds can be used to infer CPU frequency...
> > On my Nexus 6p (an Android device), the global RT runtime limit
> > seems to be set at 950ms/1sec, the root cgroup is set to 800ms/1sec, and
> > bg_non_interactive is set at 700ms/1sec.
> > 
> 
> Right, unfortunately. Still too coarse grained (as Thomas is also saying
> in his last reply, if I read it correctly).

Yes, you do. It's a big hammer and really unsuitable for this kind of
mechanism.

> Doesn't pay off the added complexity I'm afraid.

Certainly not. And the only choice we have is heuristics. Heuristic is an
euphemism for saying that it cannot work.

Thanks,

	tglx