Re: [PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

[Juri Lelli]

On 09/02/18 13:56, Rafael J. Wysocki wrote:
> On Fri, Feb 9, 2018 at 1:52 PM, Juri Lelli <juri.lelli@xxxxxxxxxx> wrote:
> > On 09/02/18 13:08, Rafael J. Wysocki wrote:
> >> On Fri, Feb 9, 2018 at 12:51 PM, Juri Lelli <juri.lelli@xxxxxxxxxx> wrote:

[...]

> >> > My impression is that rate limit helps a lot for CFS, where the "true"
> >> > utilization is not known in advance, and being too responsive might
> >> > actually be counterproductive.
> >> >
> >> > For DEADLINE (and RT, with differences) we should always respond as
> >> > quick as we can (and probably remember that a frequency transition was
> >> > requested if hw was already performing one, but that's another patch)
> >> > because, if we don't, a task belonging to a lower priority class might
> >> > induce deadline misses in highest priority activities. E.g., a CFS task
> >> > that happens to trigger a freq switch right before a DEADLINE task wakes
> >> > up and needs an higher frequency to meet its deadline: if we wait for
> >> > the rate limit of the CFS originated transition.. deadline miss!
> >>
> >> Fair enough, but if there's too much overhead as a result of this, you
> >> can't guarantee the deadlines to be met anyway.
> >
> > Indeed. I guess this only works if corner cases as the one above don't
> > happen too often.
> 
> Well, that's the point.
> 
> So there is a tradeoff: do we want to allow deadlines to be missed
> because of excessive overhead or do we want to allow deadlines to be
> missed because of the rate limit.

The difference between the two seems to be that while overhead is an
intrisic hw thing, rate limit is something we have mostly to cope with
the nature of certain classes of tasks and how we describe/track them
(at least IMHO). I'd say that for other classes of tasks (DL/RT) we
would be better off consciously living with the former only and accept
that real world is "seldom" not ideal.

But then again this is just another theory, experiments might easily
prove me wrong. :)