[igt-dev] [Intel-gfx] [PATCH i-g-t 2/3] tests/gem_eio: Speed up test execution

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-23 09:46:49)
> 
> On 22/03/2018 17:44, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-03-22 17:24:16)
> >> +       itv.it_value.tv_usec = us % 1000000;
> >> +       setitimer(ITIMER_REAL, &itv, NULL);
> > 
> > Ok, that gives a single shot signal.
> > 
> > I would have used
> > struct sigevent sev = {
> >       .sigev_notify = SIGEV_THREAD,
> >       .sigev_value.sigval_int = debugfs_dir
> >       .sigev_notify_function = hang_handler
> > };
> > timer_create(CLOCK_MONOTONIC, &sec, &timer);
> > timer_settime(timer, 0, &its, NULL);
> > 
> > Then
> > 
> > static void hang_handler(union sigval arg)
> > {
> >       igt_sysfs_set(arg.sival_int, "i915_wedged", 1);
> > }
> > 
> > No signals, nor globals required :)
> 
> I wasn't familiar with this facility.
> 
> It creates a new thread, so any hopes for small microsecond delays might 
> be ruined. I can try it if you think it is still worth it?

Yes, still worth a shot. We can always poke glibc for some smarts. Or
chase it ourselves with custom threading. We need an igt_debug() to
actually tell us how long it took to respond (from spin start to
gem_wait return).

> > The problem with using a signal is that it interrupts the gem_wait()
> > and so we don't actually check that it is being woken by the hang
> > because it is already awake. Gah.
> 
> Hm... if I am following correctly, we end up with -ERESTARTSYS and the 
> the ioctl can get restarted for us, if I would set SA_RESTART.
> 
> At the moment it happens to work because drmIoctl restart the signal.

Yes. But even automatic -ERESTARTSYS handling still implies we break
i915_request_wait() due to signal_pending_state().

> >> +static void cleanup_hang(void)
> >> +{
> >> +       struct itimerval itv = { };
> >> +
> >> +       igt_assert_eq(setitimer(ITIMER_REAL, &itv, NULL), 0);
> > 
> > You also need a sleep here as it does not flush inflight signals.
> > (Also timer_destroy :)
> 
> I always pass a longer timeout to gem_wait than the signal so I think it 
> should be guaranteed that the signal had fired before gem_wait will be 
> exiting.

I hadn't considered that. Please leave a comment as the timer
cancellation leaving pending signals inflight is something that keeps
catching me out.
-Chris