Quoting Janusz Krzysztofik (2020-02-21 13:57:26)
> Hi Chris,
>
> On Friday, February 21, 2020 10:43:21 AM CET Chris Wilson wrote:
> > +static unsigned int measure_inflight(int i915, unsigned int engine, int timeout)
> > +{
> > + IGT_CORK_FENCE(cork);
> > + struct drm_i915_gem_exec_object2 obj = {
> > + .handle = batch_create(i915)
> > + };
> > + struct drm_i915_gem_execbuffer2 execbuf = {
> > + .buffers_ptr = to_user_pointer(&obj),
> > + .buffer_count = 1,
> > + .flags = engine | I915_EXEC_FENCE_IN,
> > + .rsvd2 = igt_cork_plug(&cork, i915),
> > + };
> > + unsigned int count;
> > + int err;
> > +
> > + fcntl(i915, F_SETFL, fcntl(i915, F_GETFL) | O_NONBLOCK);
> > + igt_set_timeout(timeout, "execbuf blocked!");
> > +
> > + gem_execbuf(i915, &execbuf);
> > + for (count = 1; (err = __execbuf(i915, &execbuf)) == 0; count++)
> > + ;
> > + igt_assert_eq(err, -EWOULDBLOCK);
> > + close(execbuf.rsvd2);
> > +
> > + igt_reset_timeout();
>
> Why not right after the 'for' loop is exited? Don't we unnecessarily risk
> a race condition?
Just style, I like the grouping of the extended gem_execbuf() into a
single visual block. Either way it's a few instructions, negligible in
the grand scheme of unserialised code. We need a considerable safety
factor in any case, and yet small enough that we don't accidentally pass
with a random hangcheck.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
