All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/selftests: Pretty print the i915_active
Date: Thu, 31 Oct 2019 14:18:56 +0000	[thread overview]
Message-ID: <157253153647.11954.14804810030906563091@skylake-alporthouse-com> (raw)
In-Reply-To: <871rutknrl.fsf@gaia.fi.intel.com>

Quoting Mika Kuoppala (2019-10-31 14:11:58)
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > If the idle_pulse fails to flush the i915_active, dump the tree to see
> > if that has any clues.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >  .../drm/i915/gt/selftest_engine_heartbeat.c   |  4 ++
> >  drivers/gpu/drm/i915/i915_active.h            |  2 +
> >  drivers/gpu/drm/i915/selftests/i915_active.c  | 45 +++++++++++++++++++
> >  3 files changed, 51 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c b/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
> > index 155c508024df..131c49ddf33f 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
> > @@ -100,8 +100,12 @@ static int __live_idle_pulse(struct intel_engine_cs *engine,
> >       pulse_unlock_wait(p); /* synchronize with the retirement callback */
> >  
> >       if (!i915_active_is_idle(&p->active)) {
> > +             struct drm_printer m = drm_err_printer("pulse");
> > +
> >               pr_err("%s: heartbeat pulse did not flush idle tasks\n",
> >                      engine->name);
> > +             i915_active_print(&p->active, &m);
> > +
> >               err = -EINVAL;
> >               goto out;
> >       }
> > diff --git a/drivers/gpu/drm/i915/i915_active.h b/drivers/gpu/drm/i915/i915_active.h
> > index 4f52fe6146d2..44859356ce97 100644
> > --- a/drivers/gpu/drm/i915/i915_active.h
> > +++ b/drivers/gpu/drm/i915/i915_active.h
> > @@ -214,4 +214,6 @@ int i915_active_acquire_preallocate_barrier(struct i915_active *ref,
> >  void i915_active_acquire_barrier(struct i915_active *ref);
> >  void i915_request_add_active_barriers(struct i915_request *rq);
> >  
> > +void i915_active_print(struct i915_active *ref, struct drm_printer *m);
> > +
> >  #endif /* _I915_ACTIVE_H_ */
> > diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c b/drivers/gpu/drm/i915/selftests/i915_active.c
> > index 96513a7d4739..260b0ee5d1e3 100644
> > --- a/drivers/gpu/drm/i915/selftests/i915_active.c
> > +++ b/drivers/gpu/drm/i915/selftests/i915_active.c
> > @@ -205,3 +205,48 @@ int i915_active_live_selftests(struct drm_i915_private *i915)
> >  
> >       return i915_subtests(tests, i915);
> >  }
> > +
> > +static struct intel_engine_cs *node_to_barrier(struct active_node *it)
> > +{
> > +     struct intel_engine_cs *engine;
> > +
> > +     if (!is_barrier(&it->base))
> > +             return NULL;
> > +
> > +     engine = __barrier_to_engine(it);
> > +     smp_rmb(); /* serialise with add_active_barriers */
> 
> I did find the pair. Builds confidence.
> 
> > +     if (!is_barrier(&it->base))
> > +             return NULL;
> > +
> > +     return engine;
> > +}
> > +
> > +void i915_active_print(struct i915_active *ref, struct drm_printer *m)
> > +{
> > +     drm_printf(m, "active %pS:%pS\n", ref->active, ref->retire);
> > +     drm_printf(m, "\tcount: %d\n", atomic_read(&ref->count));
> > +     drm_printf(m, "\tpreallocated barriers? %s\n",
> > +                yesno(!llist_empty(&ref->preallocated_barriers)));
> > +
> > +     if (i915_active_acquire_if_busy(ref)) {
> > +             struct active_node *it, *n;
> > +
> > +             rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node) {
> > +                     struct intel_engine_cs *engine;
> > +
> 
> Does the aquire of ref keep the other lefs alive?
> we seem to be safe on interation but the poking about
> the fence set and timeline below is a question mark.

It prevents the tree+nodes from being freed, so we only have to worry
about the validity of the meaning of the contents.

My memory says, and my assumption in this code, is that the
the iterator is safe against insertions -- we won't get horribly lost if
the tree is rebalanced as we walk.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/selftests: Pretty print the i915_active
Date: Thu, 31 Oct 2019 14:18:56 +0000	[thread overview]
Message-ID: <157253153647.11954.14804810030906563091@skylake-alporthouse-com> (raw)
Message-ID: <20191031141856.9DW4jYDby-l-6j7YB2tM-1CJNWZas6QXb8SyVl52H1c@z> (raw)
In-Reply-To: <871rutknrl.fsf@gaia.fi.intel.com>

Quoting Mika Kuoppala (2019-10-31 14:11:58)
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > If the idle_pulse fails to flush the i915_active, dump the tree to see
> > if that has any clues.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >  .../drm/i915/gt/selftest_engine_heartbeat.c   |  4 ++
> >  drivers/gpu/drm/i915/i915_active.h            |  2 +
> >  drivers/gpu/drm/i915/selftests/i915_active.c  | 45 +++++++++++++++++++
> >  3 files changed, 51 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c b/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
> > index 155c508024df..131c49ddf33f 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
> > @@ -100,8 +100,12 @@ static int __live_idle_pulse(struct intel_engine_cs *engine,
> >       pulse_unlock_wait(p); /* synchronize with the retirement callback */
> >  
> >       if (!i915_active_is_idle(&p->active)) {
> > +             struct drm_printer m = drm_err_printer("pulse");
> > +
> >               pr_err("%s: heartbeat pulse did not flush idle tasks\n",
> >                      engine->name);
> > +             i915_active_print(&p->active, &m);
> > +
> >               err = -EINVAL;
> >               goto out;
> >       }
> > diff --git a/drivers/gpu/drm/i915/i915_active.h b/drivers/gpu/drm/i915/i915_active.h
> > index 4f52fe6146d2..44859356ce97 100644
> > --- a/drivers/gpu/drm/i915/i915_active.h
> > +++ b/drivers/gpu/drm/i915/i915_active.h
> > @@ -214,4 +214,6 @@ int i915_active_acquire_preallocate_barrier(struct i915_active *ref,
> >  void i915_active_acquire_barrier(struct i915_active *ref);
> >  void i915_request_add_active_barriers(struct i915_request *rq);
> >  
> > +void i915_active_print(struct i915_active *ref, struct drm_printer *m);
> > +
> >  #endif /* _I915_ACTIVE_H_ */
> > diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c b/drivers/gpu/drm/i915/selftests/i915_active.c
> > index 96513a7d4739..260b0ee5d1e3 100644
> > --- a/drivers/gpu/drm/i915/selftests/i915_active.c
> > +++ b/drivers/gpu/drm/i915/selftests/i915_active.c
> > @@ -205,3 +205,48 @@ int i915_active_live_selftests(struct drm_i915_private *i915)
> >  
> >       return i915_subtests(tests, i915);
> >  }
> > +
> > +static struct intel_engine_cs *node_to_barrier(struct active_node *it)
> > +{
> > +     struct intel_engine_cs *engine;
> > +
> > +     if (!is_barrier(&it->base))
> > +             return NULL;
> > +
> > +     engine = __barrier_to_engine(it);
> > +     smp_rmb(); /* serialise with add_active_barriers */
> 
> I did find the pair. Builds confidence.
> 
> > +     if (!is_barrier(&it->base))
> > +             return NULL;
> > +
> > +     return engine;
> > +}
> > +
> > +void i915_active_print(struct i915_active *ref, struct drm_printer *m)
> > +{
> > +     drm_printf(m, "active %pS:%pS\n", ref->active, ref->retire);
> > +     drm_printf(m, "\tcount: %d\n", atomic_read(&ref->count));
> > +     drm_printf(m, "\tpreallocated barriers? %s\n",
> > +                yesno(!llist_empty(&ref->preallocated_barriers)));
> > +
> > +     if (i915_active_acquire_if_busy(ref)) {
> > +             struct active_node *it, *n;
> > +
> > +             rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node) {
> > +                     struct intel_engine_cs *engine;
> > +
> 
> Does the aquire of ref keep the other lefs alive?
> we seem to be safe on interation but the poking about
> the fence set and timeline below is a question mark.

It prevents the tree+nodes from being freed, so we only have to worry
about the validity of the meaning of the contents.

My memory says, and my assumption in this code, is that the
the iterator is safe against insertions -- we won't get horribly lost if
the tree is rebalanced as we walk.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-10-31 14:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31 10:02 [PATCH] drm/i915/selftests: Pretty print the i915_active Chris Wilson
2019-10-31 10:02 ` [Intel-gfx] " Chris Wilson
2019-10-31 10:11 ` Chris Wilson
2019-10-31 10:11   ` [Intel-gfx] " Chris Wilson
2019-10-31 14:11   ` Mika Kuoppala
2019-10-31 14:11     ` [Intel-gfx] " Mika Kuoppala
2019-10-31 14:18     ` Chris Wilson [this message]
2019-10-31 14:18       ` Chris Wilson
2019-10-31 14:33       ` Chris Wilson
2019-10-31 14:33         ` [Intel-gfx] " Chris Wilson
2019-10-31 14:34   ` Mika Kuoppala
2019-10-31 14:34     ` [Intel-gfx] " Mika Kuoppala
2019-10-31 10:58 ` ✓ Fi.CI.BAT: success for drm/i915/selftests: Pretty print the i915_active (rev2) Patchwork
2019-10-31 10:58   ` [Intel-gfx] " Patchwork
2019-11-01 11:05 ` ✓ Fi.CI.IGT: " Patchwork
2019-11-01 11:05   ` [Intel-gfx] " 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=157253153647.11954.14804810030906563091@skylake-alporthouse-com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@linux.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: link
Be 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.