[igt-dev] [PATCH i-g-t] tests/gem_exec_alignment.c: Update to be completable in a rational time.

[Chris Wilson]

Quoting Grzegorzek, Dominik (2020-02-12 10:55:50)
> On Wed, 2020-02-12 at 10:02 +0000, Chris Wilson wrote:
> > Quoting Dominik Grzegorzek (2020-02-12 09:14:01)
> > > +       /*
> > > +        * Due to the high complexity of searching holes in virtual
> > > memory,
> > > +        * number of objects has to be limited. The algorithm for
> > > each alignment
> > > +        * performs execbuffer multiple times and doubles number of
> > > objects
> > > +        * in every iteration till timeout is reached.
> > > +        **/
> > >         for (alignment = 4096; alignment < gtt_size; alignment <<=
> > > 1) {
> > > -               for (i = 0; i < count; i++)
> > > -                       execobj[i].alignment = alignment;
> > > +               alignment_set_timeout(TIMEOUT);
> > > +               clock_gettime(CLOCK_MONOTONIC, &start);
> > 
> > I was thinking we made the timeout global and just run the test for a
> > maximum of N secs and see how far into the alignment loop we get?
> > 
> > There's no reason to believe that higher power of two alignments
> > provide
> > any different path coverage, just as noted we find ourselves in
> > increasingly fragmented virtual space. If you want a challenge,
> > supplement this with a priority-inversion test case... (Where a low
> > priority client can create a mess in their own address space, causing
> > a
> > delay [>10ms] of a high priority client. It's a clear and present
> > bug.)
> > -Chris
> Is that priority-inversion test case cricial for you? What about
> just making the timout global for now? 

At the moment this is a benchmark purporting to be a test. Demonstrating
that this can be abused to create a DoS is something we can use as a
regression test (since we can set hard bounds on our level of service
guarantees and assert that we do not violate them).
-Chris