From: Matthew Brost <matthew.brost@intel.com> To: John Harrison <john.c.harrison@intel.com> Cc: IGT-Dev@Lists.FreeDesktop.Org, Intel-GFX@Lists.FreeDesktop.Org Subject: Re: [Intel-gfx] [igt-dev] [PATCH v3 i-g-t 09/15] tests/i915/i915_hangman: Remove reliance on context persistance Date: Thu, 13 Jan 2022 12:38:40 -0800 [thread overview] Message-ID: <20220113203840.GA30203@jons-linux-dev-box> (raw) In-Reply-To: <2c9aca34-34ff-9bbc-f205-42850eef0256@intel.com> On Thu, Jan 13, 2022 at 12:42:28PM -0800, John Harrison wrote: > On 1/13/2022 12:30, Matthew Brost wrote: > > On Thu, Jan 13, 2022 at 11:59:41AM -0800, John.C.Harrison@Intel.com wrote: > > > From: John Harrison <John.C.Harrison@Intel.com> > > > > > > The hang test was relying on context persitence for no particular > > > reason. That is, it would set a bunch of background spinners running > > > then immediately destroy the active contexts but expect the spinners > > > to keep spinning. With the current implementation of context > > > persistence in i915, that means that super high priority pings are > > > sent to each engine at the start of the test. Depending upon the > > > timing and platform, one of those unexpected pings could cause test > > > failures. > > > > > > There is no need to require context persitence in this test. So change > > > to managing the contexts cleanly and only destroying them when they > > > are no longer in use. > > > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com> > > > --- > > > tests/i915/i915_hangman.c | 15 ++++++++++----- > > > 1 file changed, 10 insertions(+), 5 deletions(-) > > > > > > diff --git a/tests/i915/i915_hangman.c b/tests/i915/i915_hangman.c > > > index 918418760..6601db5f6 100644 > > > --- a/tests/i915/i915_hangman.c > > > +++ b/tests/i915/i915_hangman.c > > > @@ -289,27 +289,29 @@ test_engine_hang(const intel_ctx_t *ctx, > > > const struct intel_execution_engine2 *e, unsigned int flags) > > > { > > > const struct intel_execution_engine2 *other; > > > - const intel_ctx_t *tmp_ctx; > > > + const intel_ctx_t *local_ctx[GEM_MAX_ENGINES]; > > This is fine for now as GEM_MAX_ENGINES is relatively small but what if > > we change this to large value, let's say 4k? I think the stack could > > overflow then. Maybe not a concern, maybe it is? I'll leave this up to > > if this should be kmalloc'd or not in the next rev. > Seems unlikely we are going that big any time soon. And such stack reduction > can always be done as part of any huge engine count update. Although, this > is userland not kernel - you can slap gigabytes on the stack and it won't > blow up ;). > Right, I realized after I sent this the stack in user land matter far less. Should be fine. Matt > John. > > > Everything else looks good. > > > > With that: > > Reviewed-by: Matthew Brost <matthew.brost@intel.com> > > > > > igt_spin_t *spin, *next; > > > IGT_LIST_HEAD(list); > > > uint64_t ahnd = get_reloc_ahnd(device, ctx->id), ahndN; > > > + int num_ctx; > > > igt_skip_on(flags & IGT_SPIN_INVALID_CS && > > > gem_engine_has_cmdparser(device, &ctx->cfg, e->flags)); > > > /* Fill all the other engines with background load */ > > > + num_ctx = 0; > > > for_each_ctx_engine(device, ctx, other) { > > > if (other->flags == e->flags) > > > continue; > > > - tmp_ctx = intel_ctx_create(device, &ctx->cfg); > > > - ahndN = get_reloc_ahnd(device, tmp_ctx->id); > > > + local_ctx[num_ctx] = intel_ctx_create(device, &ctx->cfg); > > > + ahndN = get_reloc_ahnd(device, local_ctx[num_ctx]->id); > > > spin = __igt_spin_new(device, > > > .ahnd = ahndN, > > > - .ctx = tmp_ctx, > > > + .ctx = local_ctx[num_ctx], > > > .engine = other->flags, > > > .flags = IGT_SPIN_FENCE_OUT); > > > - intel_ctx_destroy(device, tmp_ctx); > > > + num_ctx++; > > > igt_list_move(&spin->link, &list); > > > } > > > @@ -339,7 +341,10 @@ test_engine_hang(const intel_ctx_t *ctx, > > > igt_spin_free(device, spin); > > > put_ahnd(ahndN); > > > } > > > + > > > put_ahnd(ahnd); > > > + while (num_ctx) > > > + intel_ctx_destroy(device, local_ctx[--num_ctx]); > > > check_alive(); > > > } > > > -- > > > 2.25.1 > > > >
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Brost <matthew.brost@intel.com> To: John Harrison <john.c.harrison@intel.com> Cc: IGT-Dev@Lists.FreeDesktop.Org, Intel-GFX@Lists.FreeDesktop.Org Subject: Re: [igt-dev] [PATCH v3 i-g-t 09/15] tests/i915/i915_hangman: Remove reliance on context persistance Date: Thu, 13 Jan 2022 12:38:40 -0800 [thread overview] Message-ID: <20220113203840.GA30203@jons-linux-dev-box> (raw) In-Reply-To: <2c9aca34-34ff-9bbc-f205-42850eef0256@intel.com> On Thu, Jan 13, 2022 at 12:42:28PM -0800, John Harrison wrote: > On 1/13/2022 12:30, Matthew Brost wrote: > > On Thu, Jan 13, 2022 at 11:59:41AM -0800, John.C.Harrison@Intel.com wrote: > > > From: John Harrison <John.C.Harrison@Intel.com> > > > > > > The hang test was relying on context persitence for no particular > > > reason. That is, it would set a bunch of background spinners running > > > then immediately destroy the active contexts but expect the spinners > > > to keep spinning. With the current implementation of context > > > persistence in i915, that means that super high priority pings are > > > sent to each engine at the start of the test. Depending upon the > > > timing and platform, one of those unexpected pings could cause test > > > failures. > > > > > > There is no need to require context persitence in this test. So change > > > to managing the contexts cleanly and only destroying them when they > > > are no longer in use. > > > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com> > > > --- > > > tests/i915/i915_hangman.c | 15 ++++++++++----- > > > 1 file changed, 10 insertions(+), 5 deletions(-) > > > > > > diff --git a/tests/i915/i915_hangman.c b/tests/i915/i915_hangman.c > > > index 918418760..6601db5f6 100644 > > > --- a/tests/i915/i915_hangman.c > > > +++ b/tests/i915/i915_hangman.c > > > @@ -289,27 +289,29 @@ test_engine_hang(const intel_ctx_t *ctx, > > > const struct intel_execution_engine2 *e, unsigned int flags) > > > { > > > const struct intel_execution_engine2 *other; > > > - const intel_ctx_t *tmp_ctx; > > > + const intel_ctx_t *local_ctx[GEM_MAX_ENGINES]; > > This is fine for now as GEM_MAX_ENGINES is relatively small but what if > > we change this to large value, let's say 4k? I think the stack could > > overflow then. Maybe not a concern, maybe it is? I'll leave this up to > > if this should be kmalloc'd or not in the next rev. > Seems unlikely we are going that big any time soon. And such stack reduction > can always be done as part of any huge engine count update. Although, this > is userland not kernel - you can slap gigabytes on the stack and it won't > blow up ;). > Right, I realized after I sent this the stack in user land matter far less. Should be fine. Matt > John. > > > Everything else looks good. > > > > With that: > > Reviewed-by: Matthew Brost <matthew.brost@intel.com> > > > > > igt_spin_t *spin, *next; > > > IGT_LIST_HEAD(list); > > > uint64_t ahnd = get_reloc_ahnd(device, ctx->id), ahndN; > > > + int num_ctx; > > > igt_skip_on(flags & IGT_SPIN_INVALID_CS && > > > gem_engine_has_cmdparser(device, &ctx->cfg, e->flags)); > > > /* Fill all the other engines with background load */ > > > + num_ctx = 0; > > > for_each_ctx_engine(device, ctx, other) { > > > if (other->flags == e->flags) > > > continue; > > > - tmp_ctx = intel_ctx_create(device, &ctx->cfg); > > > - ahndN = get_reloc_ahnd(device, tmp_ctx->id); > > > + local_ctx[num_ctx] = intel_ctx_create(device, &ctx->cfg); > > > + ahndN = get_reloc_ahnd(device, local_ctx[num_ctx]->id); > > > spin = __igt_spin_new(device, > > > .ahnd = ahndN, > > > - .ctx = tmp_ctx, > > > + .ctx = local_ctx[num_ctx], > > > .engine = other->flags, > > > .flags = IGT_SPIN_FENCE_OUT); > > > - intel_ctx_destroy(device, tmp_ctx); > > > + num_ctx++; > > > igt_list_move(&spin->link, &list); > > > } > > > @@ -339,7 +341,10 @@ test_engine_hang(const intel_ctx_t *ctx, > > > igt_spin_free(device, spin); > > > put_ahnd(ahndN); > > > } > > > + > > > put_ahnd(ahnd); > > > + while (num_ctx) > > > + intel_ctx_destroy(device, local_ctx[--num_ctx]); > > > check_alive(); > > > } > > > -- > > > 2.25.1 > > > >
next prev parent reply other threads:[~2022-01-13 20:44 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-13 19:59 [Intel-gfx] [PATCH v3 i-g-t 00/15] Fixes for i915_hangman and gem_exec_capture John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 01/15] tests/i915/i915_hangman: Add descriptions John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 02/15] lib/hang: Fix igt_require_hang_ring to work with all engines John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 03/15] tests/i915/i915_hangman: Update capture test to use engine structure John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 19:58 ` [Intel-gfx] " Matthew Brost 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 04/15] tests/i915/i915_hangman: Explicitly test per engine reset vs full GPU reset John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 05/15] tests/i915/i915_hangman: Add uevent test & fix detector John.C.Harrison 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 06/15] tests/i915/i915_hangman: Use the correct context in hangcheck_unterminated John.C.Harrison 2022-01-13 20:00 ` Matthew Brost 2022-01-13 20:00 ` [igt-dev] " Matthew Brost 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 07/15] lib/store: Refactor common store code into helper function John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 20:10 ` [Intel-gfx] " Matthew Brost 2022-01-13 20:27 ` John Harrison 2022-01-13 20:27 ` John Harrison 2022-01-13 20:23 ` [Intel-gfx] " Matthew Brost 2022-01-13 20:23 ` Matthew Brost 2022-01-13 20:40 ` [Intel-gfx] " John Harrison 2022-01-13 20:40 ` John Harrison 2022-01-13 20:50 ` [Intel-gfx] [PATCH i-g-t] " John.C.Harrison 2022-01-13 20:50 ` [igt-dev] " John.C.Harrison 2022-01-13 20:53 ` [Intel-gfx] " Matthew Brost 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 08/15] tests/i915/i915_hangman: Add alive-ness test after error capture John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 20:18 ` [Intel-gfx] " Matthew Brost 2022-01-13 20:18 ` [igt-dev] " Matthew Brost 2022-01-13 23:24 ` [Intel-gfx] [PATCH i-g-t] " John.C.Harrison 2022-01-13 23:24 ` [igt-dev] " John.C.Harrison 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 09/15] tests/i915/i915_hangman: Remove reliance on context persistance John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 20:30 ` [Intel-gfx] " Matthew Brost 2022-01-13 20:30 ` Matthew Brost 2022-01-13 20:42 ` [Intel-gfx] " John Harrison 2022-01-13 20:38 ` Matthew Brost [this message] 2022-01-13 20:38 ` Matthew Brost 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 10/15] tests/i915/i915_hangman: Run background task on all engines John.C.Harrison 2022-01-13 20:48 ` Matthew Brost 2022-01-13 20:48 ` [igt-dev] " Matthew Brost 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 11/15] tests/i915/i915_hangman: Don't let background contexts cause a ban John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 21:01 ` [Intel-gfx] " Matthew Brost 2022-01-13 21:01 ` Matthew Brost 2022-01-13 21:19 ` [Intel-gfx] " John Harrison 2022-01-13 21:19 ` John Harrison 2022-01-13 21:26 ` [Intel-gfx] [PATCH i-g-t] " John.C.Harrison 2022-01-13 22:30 ` Matthew Brost 2022-01-13 22:30 ` [igt-dev] " Matthew Brost 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 12/15] tests/i915/gem_exec_fence: Configure correct context John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 21:06 ` [Intel-gfx] " Matthew Brost 2022-01-13 21:23 ` John Harrison 2022-01-13 21:23 ` John Harrison 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 13/15] lib/i915: Add helper for non-destructive engine property updates John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 22:33 ` [Intel-gfx] " Matthew Brost 2022-01-13 22:33 ` Matthew Brost 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 14/15] tests/i915/i915_hangman: Configure engine properties for quicker hangs John.C.Harrison 2022-01-13 22:38 ` Matthew Brost 2022-01-13 19:59 ` [Intel-gfx] [PATCH v3 i-g-t 15/15] tests/i915/gem_exec_capture: Restore engines John.C.Harrison 2022-01-13 19:59 ` [igt-dev] " John.C.Harrison 2022-01-13 23:04 ` [Intel-gfx] " Matthew Brost 2022-01-13 23:04 ` Matthew Brost 2022-01-13 22:23 ` [igt-dev] ✗ Fi.CI.BAT: failure for Fixes for i915_hangman and gem_exec_capture (rev6) Patchwork 2022-01-13 22:53 ` Matthew Brost 2022-01-13 23:15 ` John Harrison 2022-01-13 23:25 ` [igt-dev] ✗ Fi.CI.BUILD: failure for Fixes for i915_hangman and gem_exec_capture (rev7) Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220113203840.GA30203@jons-linux-dev-box \ --to=matthew.brost@intel.com \ --cc=IGT-Dev@Lists.FreeDesktop.Org \ --cc=Intel-GFX@Lists.FreeDesktop.Org \ --cc=john.c.harrison@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.