All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 05/16] drm/i915/gt: Move the breadcrumb to the signaler if completed upon cancel
Date: Tue, 24 Nov 2020 16:30:52 +0000	[thread overview]
Message-ID: <160623545286.28476.12142656128812295838@build.alporthouse.com> (raw)
In-Reply-To: <f1089ea3-bfa6-1290-f0bd-5214a36e257a@linux.intel.com>

Quoting Tvrtko Ursulin (2020-11-24 16:19:15)
> 
> On 24/11/2020 11:42, Chris Wilson wrote:
> > If while we are cancelling the breadcrumb signaling, we find that the
> > request is already completed, move it to the irq signaler and let it be
> > signaled.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >   drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 20 ++++++++++++++++----
> >   1 file changed, 16 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> > index a24cc1ff08a0..f5f6feed0fa6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> > @@ -363,6 +363,14 @@ void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
> >       kfree(b);
> >   }
> >   
> > +static void irq_signal_request(struct i915_request *rq,
> > +                            struct intel_breadcrumbs *b)
> > +{
> > +     if (__signal_request(rq) &&
> > +         llist_add(&rq->signal_node, &b->signaled_requests))
> > +             irq_work_queue(&b->irq_work);
> > +}
> > +
> >   static void insert_breadcrumb(struct i915_request *rq)
> >   {
> >       struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
> > @@ -380,9 +388,7 @@ static void insert_breadcrumb(struct i915_request *rq)
> >        * its signal completion.
> >        */
> >       if (__request_completed(rq)) {
> > -             if (__signal_request(rq) &&
> > -                 llist_add(&rq->signal_node, &b->signaled_requests))
> > -                     irq_work_queue(&b->irq_work);
> > +             irq_signal_request(rq, b);
> >               return;
> >       }
> >   
> > @@ -453,6 +459,7 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
> >   
> >   void i915_request_cancel_breadcrumb(struct i915_request *rq)
> >   {
> > +     struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
> >       struct intel_context *ce = rq->context;
> >       bool release;
> >   
> > @@ -461,11 +468,16 @@ void i915_request_cancel_breadcrumb(struct i915_request *rq)
> >   
> >       spin_lock(&ce->signal_lock);
> >       list_del_rcu(&rq->signal_link);
> > -     release = remove_signaling_context(rq->engine->breadcrumbs, ce);
> > +     release = remove_signaling_context(b, ce);
> >       spin_unlock(&ce->signal_lock);
> >       if (release)
> >               intel_context_put(ce);
> >   
> > +     if (__request_completed(rq)) {
> > +             irq_signal_request(rq, b);
> > +             return;
> 
> This is a bit unintuitive - irq_signal_request does things conditionally 
> based on the signaled flag, but here the return value is ignored and 
> reference kept regardless. Which makes me wonder how can the combo of 
> the two always dtrt. Because __request_completed is seqno based, which 
> can happen before setting the signaled flag. Like if retire races with 
> breadcrumbs. Am I missing something?

static void irq_signal_request()

Yes, the completion must happen before the signal bit is set, and there
is race on who sets the signal bit.

So if, and only if, __signal_request() is the first to set the signal
bit do we keep the reference to the request and enqueue it to execute the
callbacks in the irq-worker.

If the request is completed, but someone else has already signaled the
request, the reference is dropped.

static bool __signal_request(struct i915_request *rq)
{
        GEM_BUG_ON(test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags));

        if (!__dma_fence_signal(&rq->fence)) {
                i915_request_put(rq);
                return false;
        }

        return true;
}

I see your point that the reference handling is not obvious. Worth
taking another pass over it to split the different paths into their
different ways so the ownership is not hidden away.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-11-24 16:31 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24 11:42 [Intel-gfx] [PATCH 01/16] drm/i915/gem: Drop free_work for GEM contexts Chris Wilson
2020-11-24 11:42 ` [Intel-gfx] [PATCH 02/16] drm/i915/gt: Track the overall awake/busy time Chris Wilson
2020-11-24 11:42 ` [Intel-gfx] [PATCH 03/16] drm/i915/gt: Protect context lifetime with RCU Chris Wilson
2020-11-24 11:42 ` [Intel-gfx] [PATCH 04/16] drm/i915/gt: Split the breadcrumb spinlock between global and contexts Chris Wilson
2020-11-24 11:42 ` [Intel-gfx] [PATCH 05/16] drm/i915/gt: Move the breadcrumb to the signaler if completed upon cancel Chris Wilson
2020-11-24 16:19   ` Tvrtko Ursulin
2020-11-24 16:30     ` Chris Wilson [this message]
2020-11-24 17:02       ` Tvrtko Ursulin
2020-11-25 19:56   ` [Intel-gfx] [PATCH v2] " Chris Wilson
2020-11-26 11:32     ` Tvrtko Ursulin
2020-11-24 11:42 ` [Intel-gfx] [PATCH 06/16] drm/i915/gt: Decouple completed requests on unwind Chris Wilson
2020-11-24 17:13   ` Tvrtko Ursulin
2020-11-24 17:31     ` Chris Wilson
2020-11-25  9:15       ` Tvrtko Ursulin
2020-11-25 10:21         ` Chris Wilson
2020-11-25 16:21           ` Tvrtko Ursulin
2020-11-24 11:42 ` [Intel-gfx] [PATCH 07/16] drm/i915/gt: Check for a completed last request once Chris Wilson
2020-11-24 17:19   ` Tvrtko Ursulin
2020-11-24 17:38     ` Chris Wilson
2020-11-25  8:59       ` Tvrtko Ursulin
2020-11-24 11:42 ` [Intel-gfx] [PATCH 08/16] drm/i915/gt: Replace direct submit with direct call to tasklet Chris Wilson
2020-11-24 11:42 ` [Intel-gfx] [PATCH 09/16] drm/i915/gt: ce->inflight updates are now serialised Chris Wilson
2020-11-25  9:34   ` Tvrtko Ursulin
2020-11-24 11:42 ` [Intel-gfx] [PATCH 10/16] drm/i915/gt: Use virtual_engine during execlists_dequeue Chris Wilson
2020-11-24 11:42 ` [Intel-gfx] [PATCH 11/16] drm/i915/gt: Decouple inflight virtual engines Chris Wilson
2020-11-24 11:42 ` [Intel-gfx] [PATCH 12/16] drm/i915/gt: Defer schedule_out until after the next dequeue Chris Wilson
2020-11-24 11:42 ` [Intel-gfx] [PATCH 13/16] drm/i915/gt: Remove virtual breadcrumb before transfer Chris Wilson
2020-11-24 11:42 ` [Intel-gfx] [PATCH 14/16] drm/i915/gt: Shrink the critical section for irq signaling Chris Wilson
2020-11-24 11:42 ` [Intel-gfx] [PATCH 15/16] drm/i915/gt: Resubmit the virtual engine on schedule-out Chris Wilson
2020-11-24 11:42 ` [Intel-gfx] [PATCH 16/16] drm/i915/gt: Simplify virtual engine handling for execlists_hold() Chris Wilson
2020-11-24 14:15 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/16] drm/i915/gem: Drop free_work for GEM contexts Patchwork
2020-11-24 14:16 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-11-24 14:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-11-24 18:04 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-11-25 21:02 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/16] drm/i915/gem: Drop free_work for GEM contexts (rev2) Patchwork
2020-11-25 21:04 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-11-25 21:32 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-11-25 23:34 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=160623545286.28476.12142656128812295838@build.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@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.