All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Prevent recursion by retiring requests when the ring is full
Date: Tue, 28 Jan 2014 13:15:35 +0200	[thread overview]
Message-ID: <20140128111535.GV9454@intel.com> (raw)
In-Reply-To: <1390862587-26669-1-git-send-email-chris@chris-wilson.co.uk>

On Mon, Jan 27, 2014 at 10:43:07PM +0000, Chris Wilson wrote:
> As the VM do not track activity of objects and instead use a large
> hammer to forcibly idle and evict all of their associated objects when
> one is released, it is possible for that to cause a recursion when we
> need to wait for free space on a ring and call retire requests.
> (intel_ring_begin -> intel_ring_wait_request ->
> i915_gem_retire_requests_ring -> i915_gem_context_free ->
> i915_gem_evict_vm -> i915_gpu_idle -> intel_ring_begin etc)
> 
> In order to remove the requirement for calling retire-requests from
> intel_ring_wait_request, we have to inline a couple of steps from
> retiring requests, notably we have to record the position of the request
> we wait for and use that to update the available ring space.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Looks good to me.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

I do have a couple of questions about request->tail though.

We set it to -1 in intel_ring_wait_request(). Isn't that going to cause
problems for i915_request_guilty()?

When not -1, request->tail points to just before the commands that
.add_request() adds to the ring. So that means intel_ring_wait_request()
might have to wait for one extra request, and I guess more importantly
if the GPU hangs inside the .add_request() commands, we won't attribute
the hang to the request in question. Was it designe to be that way, or
is there a bug here?

> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 25 +++++--------------------
>  1 file changed, 5 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 10ff32d09c14..0da7c257159a 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1431,28 +1431,16 @@ void intel_cleanup_ring_buffer(struct intel_ring_buffer *ring)
>  	cleanup_status_page(ring);
>  }
>  
> -static int intel_ring_wait_seqno(struct intel_ring_buffer *ring, u32 seqno)
> -{
> -	int ret;
> -
> -	ret = i915_wait_seqno(ring, seqno);
> -	if (!ret)
> -		i915_gem_retire_requests_ring(ring);
> -
> -	return ret;
> -}
> -
>  static int intel_ring_wait_request(struct intel_ring_buffer *ring, int n)
>  {
>  	struct drm_i915_gem_request *request;
> -	u32 seqno = 0;
> +	u32 seqno = 0, tail;
>  	int ret;
>  
> -	i915_gem_retire_requests_ring(ring);
> -
>  	if (ring->last_retired_head != -1) {
>  		ring->head = ring->last_retired_head;
>  		ring->last_retired_head = -1;
> +
>  		ring->space = ring_space(ring);
>  		if (ring->space >= n)
>  			return 0;
> @@ -1469,6 +1457,7 @@ static int intel_ring_wait_request(struct intel_ring_buffer *ring, int n)
>  			space += ring->size;
>  		if (space >= n) {
>  			seqno = request->seqno;
> +			tail = request->tail;
>  			break;
>  		}
>  
> @@ -1483,15 +1472,11 @@ static int intel_ring_wait_request(struct intel_ring_buffer *ring, int n)
>  	if (seqno == 0)
>  		return -ENOSPC;
>  
> -	ret = intel_ring_wait_seqno(ring, seqno);
> +	ret = i915_wait_seqno(ring, seqno);
>  	if (ret)
>  		return ret;
>  
> -	if (WARN_ON(ring->last_retired_head == -1))
> -		return -ENOSPC;
> -
> -	ring->head = ring->last_retired_head;
> -	ring->last_retired_head = -1;
> +	ring->head = tail;
>  	ring->space = ring_space(ring);
>  	if (WARN_ON(ring->space < n))
>  		return -ENOSPC;
> -- 
> 1.8.5.3
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

  parent reply	other threads:[~2014-01-28 11:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-27 22:43 [PATCH] drm/i915: Prevent recursion by retiring requests when the ring is full Chris Wilson
2014-01-28  8:11 ` Daniel Vetter
2014-01-28  8:22   ` Chris Wilson
2014-01-28  8:27     ` Daniel Vetter
2014-01-28 11:15 ` Ville Syrjälä [this message]
2014-01-28 11:25   ` Chris Wilson
2014-02-06 16:44     ` Daniel Vetter

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=20140128111535.GV9454@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.