| Message ID | 20180615185643.15359-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 15/06/18 11:56, Chris Wilson wrote: > As we hang ctx0 quite frequently, it needs to be harden against being > banned. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Mika Kuoppala <mika.kuoppala@intel.com> For some reason I thought we had more hang stress tests. Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com> > --- > tests/gem_eio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/gem_eio.c b/tests/gem_eio.c > index e1aff639d..5faf7502b 100644 > --- a/tests/gem_eio.c > +++ b/tests/gem_eio.c > @@ -642,7 +642,7 @@ static void test_inflight_internal(int fd, unsigned int wait) > */ > static void test_reset_stress(int fd, unsigned int flags) > { > - uint32_t ctx0 = gem_context_create(fd); > + uint32_t ctx0 = context_create_safe(fd); I guess until (before Mika's patch) now we were covered by 'ctx' being created and destroyed all the time. Thanks, Antonio > > igt_until_timeout(5) { > struct drm_i915_gem_execbuffer2 execbuf = { }; >
Quoting Antonio Argenziano (2018-06-15 21:23:51) > > > On 15/06/18 11:56, Chris Wilson wrote: > > As we hang ctx0 quite frequently, it needs to be harden against being > > banned. > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Mika Kuoppala <mika.kuoppala@intel.com> > > For some reason I thought we had more hang stress tests. We do lots of resets, but not a lot of hangcheck testing (because hangcheck requires waiting for a long time). gem_exec_whisper is a good example if you want to wait a day for each hang subtest. > Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com> > > > --- > > tests/gem_eio.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/gem_eio.c b/tests/gem_eio.c > > index e1aff639d..5faf7502b 100644 > > --- a/tests/gem_eio.c > > +++ b/tests/gem_eio.c > > @@ -642,7 +642,7 @@ static void test_inflight_internal(int fd, unsigned int wait) > > */ > > static void test_reset_stress(int fd, unsigned int flags) > > { > > - uint32_t ctx0 = gem_context_create(fd); > > + uint32_t ctx0 = context_create_safe(fd); > > I guess until (before Mika's patch) now we were covered by 'ctx' > being created and destroyed all the time. Before it was just that we only counted *banned* contexts against the client, and ctx0 has a good mix of valid batches to offset the few hangs so it didn't get banned. It's a fair question that maybe we have the heuristics wrong if the client gets banned before the context. -Chris
diff --git a/tests/gem_eio.c b/tests/gem_eio.c index e1aff639d..5faf7502b 100644 --- a/tests/gem_eio.c +++ b/tests/gem_eio.c @@ -642,7 +642,7 @@ static void test_inflight_internal(int fd, unsigned int wait) */ static void test_reset_stress(int fd, unsigned int flags) { - uint32_t ctx0 = gem_context_create(fd); + uint32_t ctx0 = context_create_safe(fd); igt_until_timeout(5) { struct drm_i915_gem_execbuffer2 execbuf = { };
As we hang ctx0 quite frequently, it needs to be harden against being banned. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> --- tests/gem_eio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)