[igt-dev] [PATCH i-g-t 3/3] igt/gem_sync: Exercising waiting while keeping the GPU busy

[Chris Wilson]

Quoting Antonio Argenziano (2018-08-10 18:41:22)
> 
> 
> On 10/08/18 04:01, Chris Wilson wrote:
> > Normally we wait on the last request, but that overlooks any
> > difficulties in waiting on a request while the next is being qeued.
> 
> /s/qeued/queued
> 
> > Check those.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> >   tests/gem_sync.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++
> >   1 file changed, 72 insertions(+)
> > 
> > diff --git a/tests/gem_sync.c b/tests/gem_sync.c
> > index c697220ad..fb209977d 100644
> > --- a/tests/gem_sync.c
> > +++ b/tests/gem_sync.c
> > @@ -294,6 +294,74 @@ wakeup_ring(int fd, unsigned ring, int timeout, int wlen)
> >       igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
> >   }
> >   
> 
> > +     intel_detect_and_clear_missed_interrupts(fd);
> > +     igt_fork(child, num_engines) {
> > +             double start, end, elapsed;
> > +             unsigned long cycles;
> > +             igt_spin_t *spin[2];
> > +             uint32_t cmd;
> > +
> > +             spin[0] = __igt_spin_batch_new(fd,
> > +                                            .engine = ring,
> > +                                            .flags = IGT_SPIN_FAST);
> > +             cmd = *spin[0]->batch;
> > +
> > +             spin[1] = __igt_spin_batch_new(fd,
> > +                                            .engine = ring,
> > +                                            .flags = IGT_SPIN_FAST);
> > +             igt_assert(*spin[1]->batch == cmd);
> > +
> > +             start = gettime();
> > +             end = start + timeout;
> > +             cycles = 0;
> > +             do {
> > +                     for (int loop = 0; loop < 1024; loop++) {
> > +                             igt_spin_t *s = spin[loop & 1];
> > +
> > +                             igt_spin_batch_end(s);
> > +                             gem_sync(fd, s->handle);
> 
> How does the test fail if the sync goes wrong? Hang detector on the 
> queued batch?

We have a hang detector for both missed wakeups and GPU hangs. As tests
goes it's fairly tame, but in essence this entire file is about trying
to trick the HW+driver into not sending an interrupt back to userspace.
Just a very narrow stress test, over and over again from slightly
different angles.
-Chris