Quoting Tvrtko Ursulin (2018-04-11 14:52:36)
> On 11/04/2018 14:23, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-04-04 10:51:52)
> >> From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> >> Realtime scheduling interferes with execlists submission (tasklet) so try
> >> to simplify the PWM loop in a few ways:
> >> * Drop RT.
> >> * Longer batches for smaller systematic error.
> >> * More truthful test duration calculation.
> >> * Less clock queries.
> >> * No self-adjust - instead just report the achieved cycle and let the
> >> parent check against it.
> >> * Report absolute cycle error.
> >> v2:
> >> * Bring back self-adjust. (Chris Wilson)
> >> (But slightly fixed version with no overflow.)
> >> v3:
> >> * Log average and mean calibration for each pass.
> >> v4:
> >> * Eliminate development leftovers.
> >> * Fix variance logging.
> >> Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> > From a pragmatic point of view, there's no point waiting for me to be
> > happy with the convergence if CI is, and the variance will definitely be
> > interesting (although you could have used igt_mean to compute the
> > iterative variance), so
> > Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Thanks, I've pushed it and so we'll see.
We should resurrect the RT variant in the near future. It's definitely
an issue in our driver that random userspace can impact execution of
unconnected others. (Handling RT starvation of workers is something we
have to be aware of elsewhere, commonly hits oom if we don't have an
escape clause.) Lots of words just to say, we should add a test for RT
to exercise the bad behaviour. Hmm, doesn't need to be pmu, just we need
an assertion that execution latency is bounded and no RT hog will delay
Intel-gfx mailing list