[Intel-gfx] [PATCH i-g-t v2 0/1] tests/i915/perf: Add stress / race exercises

[Janusz Krzysztofik]

On Friday, 10 February 2023 12:56:12 CET Janusz Krzysztofik wrote:
> On Friday, 10 February 2023 12:21:58 CET Kamil Konieczny wrote:
> > Hi,
> > 
> > On 2023-02-10 at 08:53:12 +0100, Janusz Krzysztofik wrote:
> > > Hi,
> > > 
> > > On Thursday, 9 February 2023 12:50:38 CET Janusz Krzysztofik wrote:
> > > > Users reported oopses on list corruptions when using i915 perf with a
> > > > number of concurrently running graphics applications.  That indicates we
> > > > are currently missing some important tests for such scenarios.  Cover
> > > > that gap.
> > > > 
> > > > v2: drop open-race subtest for now, not capable of triggering the user
> > > >     reported bug, but triggering other bugs which I can't see any fixes
> > > >     for queued yet,
> > > >   - move the other new subtest out of tests/i915/perf.c (Ashutosh).
> > > > 
> > > > Janusz Krzysztofik (1):
> > > >   tests/gem_ctx_exec: Exercise barrier race
> > > 
> > > While still waiting for CI results (BAT results don't cover the new subtest) 
> > > I've collected results from a forced execution of the subtest in BAT scope on 
> > > trybot: https://patchwork.freedesktop.org/series/113608/#rev2
> > > 
> > > While working as expected on most platforms, the test failed on some ancient 
> > > ones instead of skipping.  I've fixed this issue and tested the fix 
> > > successfully on trybot: https://patchwork.freedesktop.org/series/113608/#rev3
> > > 
> > > I'm still waiting for your comments, if any, before I submit the fixed 
> > > version.
> > 
> > Patch looks good but as you already noticed it is blacklisted
> > and do not cause noticeable fail. Proposed solution is to move
> > it to other test or to create new one, imho one you proposed
> > 
> > igt at gem_barrier_race@remote-request
> 
> OK, since I can't point out any better existing candidate, let's create a new 
> test.  However, taking into account that we have some more variants in 
> progress which differ on the barrier rather then remote-request side 
> of workloads, and the remote-request workload will probably be common to all 
> those variants, I propose a somehow reordered test naming:
> 
> igt at gem_remote_request@barrier-race

I've decided to keep my initial igt at gem_barrier_race@remote-request naming.
Since implementation of barrier tasks list handling is intentionally racy, 
I think that's quite reasonable to have a test focused on exercising those 
race cases, and the remote-request case seems not the only one that can be
problematic.

Thanks,
Janusz


> 
> This way, we don't determine how remote requests are triggered, then we don't 
> connect the new test with perf specifically in any way, and we have plenty of 
> room for different workloads we may want to race against remote requests (be 
> it perf triggered or not).
> 
> If perf specifically requires more thorough testing, that can be handled 
> separately in a separate, perf dedicated test.
> 
> Thanks,
> Janusz
> 
> 
> > 
> > looks good.
> > 
> > Regards,
> > Kamil
> > 
> > > 
> > > Thanks,
> > > Janusz
> > > 
> > > > 
> > > >  tests/i915/gem_ctx_exec.c | 123 ++++++++++++++++++++++++++++++++++++++
> > > >  tests/meson.build         |   9 ++-
> > > >  2 files changed, 131 insertions(+), 1 deletion(-)
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> 
> 
> 
> 
>