Re: [PATCH 10/12] drm/i915/execlists: Reduce lock contention between schedule/submit_request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 15/05/2017 11:55, Chris Wilson wrote:
On Mon, May 15, 2017 at 11:51:52AM +0100, Tvrtko Ursulin wrote:

On 11/05/2017 20:59, Chris Wilson wrote:
If we do not require to perform priority bumping, and we haven't yet
submitted the request, we can update its priority in situ and skip
acquiring the engine locks -- thus avoiding any contention between us
and submit/execute.

v2: Remove the stack element from the list if we can do the early
assignment.

Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
---
drivers/gpu/drm/i915/intel_lrc.c | 13 +++++++++++++
1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7e41529bd074..3cfb4b145b75 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -767,6 +767,19 @@ static void execlists_schedule(struct drm_i915_gem_request *request, int prio)
		list_safe_reset_next(dep, p, dfs_link);
	}

+	/* If we didn't need to bump any existing priorities, and we haven't
+	 * yet submitted this request (i.e. there is no potential race with
+	 * execlists_submit_request()), we can set our own priority and skip
+	 * acquiring the engine locks.
+	 */
+	if (request->priotree.priority == INT_MIN) {
+		GEM_BUG_ON(!list_empty(&request->priotree.link));
+		request->priotree.priority = prio;
+		if (stack.dfs_link.next == stack.dfs_link.prev)
+			return;
+		__list_del_entry(&stack.dfs_link);

Hm is early processing the out of queue request with no dependencies
safe? Recently you fixed a race in this area, which AFAIK was about
doing that outside the engine lock and then request becoming ready
in parallel, racing with the FIFO order.

Yes. In this case we know that we have commited the request as we are in
i915_add_request (the only time we may schedule with prio == INT_MIN).

Okay, sounds safe in that case.

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

Regards,

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux