Re: [PATCH i-g-t v4] tests/perf_pmu: Avoid RT thread for accuracy test

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	igt-dev@lists.freedesktop.org
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH i-g-t v4] tests/perf_pmu: Avoid RT thread for accuracy test
Date: Mon, 16 Apr 2018 11:08:46 +0100	[thread overview]
Message-ID: <152387332633.2662.10927343912049488536@mail.alporthouse.com> (raw)
In-Reply-To: <476803d1-9c91-2dff-f48d-457a42ba0ab1@linux.intel.com>

Quoting Tvrtko Ursulin (2018-04-16 10:55:29)
> 
> On 14/04/2018 12:35, Chris Wilson wrote:
> > 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.ursulin@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.ursulin@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 <chris@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
> > it.
> 
> Agreed, I can add a simple test to gem_exec_latency.
> 
> But with regards on how to fix this - re-enabling direct submission 
> sounds simplest (not only indirect via tasklet) in theory although I do 
> remember you were raising some issues with this route last time I 
> mentioned it. It does sound like a conceptually correct thing to do.

The problem comes down to that we want direct submission from the irq
handler, which the tasklet solves very nicely for us (most of the time).
Finding an alternative hook other than irq_exit() is the challenge,
irq_work might be acceptable.

> As an alternative we could explore conversion effort and resulting 
> latencies from conversion to threaded irq handler.

* shivers

Then we have at least consistently bad latency ;) And the sysadmin can
decide how to prioritise, boo.

> You also had a patch to improve tasklet scheduling in some cases now I 
> remember. We can try that after I write the test as well. Although I 
> have no idea how hard of a sell that would be.

I think the next plan for upstream tasklets is to try and avoid having
one vector influence the ksoftirqd latency of another. However, that
doesn't solve it for us, where it's likely we've consumed the tasklet
timeslice and so will still be deferred onto ksoftirqd. (It just solves
the case of netdev forcing us to ksoftirqd along with itself.) The hack
I use on top of that to always do at least one immediate execution of
HISOFTIRQ boils down to why just allow that special case, to which there
is no good answer.

Hmm, irq_work, my only concern is if it is run with irqs disabled. We
could live without, but that's an alarmingly big chunk of code.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx