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@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@gem_remote_request@barrier-race 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(-) > > > > > > > > > > > > > > >
