All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: More proactive timeline retirement before new requests
Date: Mon, 13 Jan 2020 14:12:09 +0000	[thread overview]
Message-ID: <157892472988.27314.12207020919416356123@skylake-alporthouse-com> (raw)
In-Reply-To: <20200113140715.1868017-1-chris@chris-wilson.co.uk>

Quoting Chris Wilson (2020-01-13 14:07:15)
> @@ -1344,28 +1330,6 @@ void i915_request_add(struct i915_request *rq)
>         __i915_request_queue(rq, &attr);
>         local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
>  
> -       /*
> -        * In typical scenarios, we do not expect the previous request on
> -        * the timeline to be still tracked by timeline->last_request if it
> -        * has been completed. If the completed request is still here, that
> -        * implies that request retirement is a long way behind submission,
> -        * suggesting that we haven't been retiring frequently enough from
> -        * the combination of retire-before-alloc, waiters and the background
> -        * retirement worker. So if the last request on this timeline was
> -        * already completed, do a catch up pass, flushing the retirement queue
> -        * up to this client. Since we have now moved the heaviest operations
> -        * during retirement onto secondary workers, such as freeing objects
> -        * or contexts, retiring a bunch of requests is mostly list management
> -        * (and cache misses), and so we should not be overly penalizing this
> -        * client by performing excess work, though we may still performing
> -        * work on behalf of others -- but instead we should benefit from
> -        * improved resource management. (Well, that's the theory at least.)
> -        */
> -       if (prev &&
> -           i915_request_completed(prev) &&
> -           rcu_access_pointer(prev->timeline) == tl)
> -               i915_request_retire_upto(prev);

Hmm, the argument in favour of retiring after submitting the request is still
reasonable, i.e. try not to add latency before the next request.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-01-13 14:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13 14:04 [Intel-gfx] [PATCH] drm/i915: Preemptive timeline retirement Chris Wilson
2020-01-13 14:05 ` Chris Wilson
2020-01-13 14:07 ` [Intel-gfx] [PATCH] drm/i915: More proactive timeline retirement before new requests Chris Wilson
2020-01-13 14:12   ` Chris Wilson [this message]
2020-01-13 14:16   ` [Intel-gfx] [PATCH v2] " Chris Wilson
2020-01-13 15:15 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Preemptive timeline retirement (rev3) Patchwork
2020-01-13 15:40 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-01-13 15:40 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning " Patchwork
2020-01-15 15:05 ` [Intel-gfx] ✓ Fi.CI.IGT: success " 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=157892472988.27314.12207020919416356123@skylake-alporthouse-com \
    --to=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.