[Intel-gfx] [PATCH 1/5] drm/i915/selftests: Skip unstable timing measurements

Chris Wilson chris at chris-wilson.co.uk
Fri Jan 8 13:54:35 UTC 2021


Quoting Andi Shyti (2021-01-08 13:51:54)
> Hi Chris,
> 
> > > > diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> > > > index 75839db63bea..59c58a276677 100644
> > > > --- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> > > > +++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> > > > @@ -852,6 +852,9 @@ static int _perf_memcpy(struct intel_memory_region *src_mr,
> > > >               }
> > > >  
> > > >               sort(t, ARRAY_SIZE(t), sizeof(*t), wrap_ktime_compare, NULL);
> > > > +             if (!t[0])
> > > > +                     continue;
> > > > +
> > > 
> > > are you assuming here that if t[0] is '0', also the rest of 't'
> > > is '0'?
> > 
> > It's sorted into ascending order with ktime_t... Hmm, s64 not u64 as I
> > presumed. So better to check <= 0.
> 
> by division by 0 I guess you mean here:
> 
>         div64_u64(mul_u32_u32(4 * size,
>                               1000 * 1000 * 1000),
>                   t[1] + 2 * t[2] + t[3]) >> 20);
> 
> why are you testing t[0]? Did I miss anything else?

Since t[0] is the most negative value, if it is <= 0 that implies at
least one of the measurements was bad. If any are bad, all are bad by
association. I considered checking t[4] to make sure that at least the
best was good enough, but paranoia won.
-Chris


More information about the Intel-gfx mailing list