All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org,
	Mika Kuoppala <mika.kuoppala@intel.com>
Subject: Re: [PATCH 6/6] drm/i915: Only attempt to signal the request once from the interrupt handler
Date: Wed, 15 Mar 2017 20:09:18 +0000	[thread overview]
Message-ID: <83fbe902-ecd2-336a-fa17-2af1e3da8c1e@linux.intel.com> (raw)
In-Reply-To: <20170315200554.GL2118@nuc-i3427.alporthouse.com>


On 15/03/2017 20:05, Chris Wilson wrote:
> On Wed, Mar 15, 2017 at 07:47:20PM +0000, Tvrtko Ursulin wrote:
>>
>> On 15/03/2017 14:01, Chris Wilson wrote:
>>> Check that signaled bit on the request->fence before acquiring a
>>
>>             "is not set" ^
>>
>> Or "Check that the request has not been signalled before.." ?
>>
>>> reference to the request for signaling later in the interrupt handler.
>>>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Mika Kuoppala <mika.kuoppala@intel.com>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> ---
>>> drivers/gpu/drm/i915/i915_irq.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
>>> index 31f0d7c8992f..e646c4eba65d 100644
>>> --- a/drivers/gpu/drm/i915/i915_irq.c
>>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>>> @@ -1056,7 +1056,9 @@ static void notify_ring(struct intel_engine_cs *engine)
>>> 		 * and many waiters.
>>> 		 */
>>> 		if (i915_seqno_passed(intel_engine_get_seqno(engine),
>>> -				      wait->seqno))
>>> +				      wait->seqno) &&
>>> +		    !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
>>> +			      &wait->request->fence.flags))
>>> 			rq = i915_gem_request_get(wait->request);
>>>
>>> 		wake_up_process(wait->tsk);
>>>
>>
>> Is this just to optimize things slightly? Does it happen
>> sufficiently often for it to be worth it?
>
> Even once would be enough. An unlocked read of fence.flags is much
> cheaper than the locked get/put we go through otherwise. Even if the
> check is a dud, the load of the cacheline prior to us making it
> exclusive is "free".
>
> I'm mostly thinking about the situations where we have pile of bare
> breadcrumbs where we may very well get interrupts faster than we can get
> rid of the intel_wait. Or perhaps a mythical slow device.

Makes sense now that you've said it. Maybe c&p into the commit as well. ;)

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-03-15 20:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-15 14:01 [PATCH 1/6] drm/i915/breadcrumbs: Use booleans for intel_breadcrumbs_busy() Chris Wilson
2017-03-15 14:01 ` [PATCH 2/6] drm/i915/breadcrumbs: Assert that irqs are disabled as we update the bottom-half Chris Wilson
2017-03-15 18:20   ` Tvrtko Ursulin
2017-03-15 18:32     ` Chris Wilson
2017-03-15 19:01       ` Tvrtko Ursulin
2017-03-15 14:01 ` [PATCH 3/6] drm/i915/breadcrumbs: Update bottom-half before marking as complete Chris Wilson
2017-03-15 18:58   ` Tvrtko Ursulin
2017-03-15 19:10     ` Chris Wilson
2017-03-15 19:30       ` Tvrtko Ursulin
2017-03-15 14:01 ` [PATCH 4/6] drm/i915/breadcrumbs: Disable interrupt bottom-half first on idling Chris Wilson
2017-03-15 19:33   ` Tvrtko Ursulin
2017-03-15 14:01 ` [PATCH 5/6] drm/i915/breadcrumbs: Assert that we do not shortcut the current bottom-half Chris Wilson
2017-03-15 19:40   ` Tvrtko Ursulin
2017-03-15 14:01 ` [PATCH 6/6] drm/i915: Only attempt to signal the request once from the interrupt handler Chris Wilson
2017-03-15 19:47   ` Tvrtko Ursulin
2017-03-15 20:05     ` Chris Wilson
2017-03-15 20:09       ` Tvrtko Ursulin [this message]
2017-03-15 14:52 ` ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/breadcrumbs: Use booleans for intel_breadcrumbs_busy() Patchwork
2017-03-15 18:03 ` [PATCH 1/6] " Tvrtko Ursulin

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=83fbe902-ecd2-336a-fa17-2af1e3da8c1e@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@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.