We have:

- intel_context_timeline_lock() - intel_context_timeline_unlock()

In the next patches we will also need:

- intel_context_timeline_is_locked()

Add it.

Signed-off-by: Andi Shyti andi.shyti@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Nirmoy Das nirmoy.das@intel.com --- drivers/gpu/drm/i915/gt/intel_context.h | 6 ++++++ 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h index 48f888c3da083..f2f79ff0dfd1d 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.h +++ b/drivers/gpu/drm/i915/gt/intel_context.h @@ -270,6 +270,12 @@ static inline void intel_context_timeline_unlock(struct intel_timeline *tl) mutex_unlock(&tl->mutex); }

+static inline void intel_context_assert_timeline_is_locked(struct intel_timeline *tl) + __must_hold(&tl->mutex) +{ + lockdep_assert_held(&tl->mutex); +} + int intel_context_prepare_remote_request(struct intel_context *ce, struct i915_request *rq);

i915_request_add() assumes that the timeline is locked whtn the function is called. Before exiting it releases the lock. But in the next commit we have one case where releasing the timeline mutex is not necessary and we don't want that.

Make a new i915_request_add_locked() version of the function where the lock is not released.

Signed-off-by: Andi Shyti andi.shyti@linux.intel.com Cc: stable@vger.kernel.org --- drivers/gpu/drm/i915/i915_request.c | 14 +++++++++++--- drivers/gpu/drm/i915/i915_request.h | 1 + 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 58662360ac34e..21032b3b9d330 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1852,13 +1852,13 @@ void __i915_request_queue(struct i915_request *rq, local_bh_enable(); /* kick tasklets */ }

-void i915_request_add(struct i915_request *rq) +void i915_request_add_locked(struct i915_request *rq) { struct intel_timeline * const tl = i915_request_timeline(rq); struct i915_sched_attr attr = {}; struct i915_gem_context *ctx;

- lockdep_assert_held(&tl->mutex); + intel_context_assert_timeline_is_locked(tl); lockdep_unpin_lock(&tl->mutex, rq->cookie);

trace_i915_request_add(rq); @@ -1873,7 +1873,15 @@ void i915_request_add(struct i915_request *rq)

__i915_request_queue(rq, &attr);

- mutex_unlock(&tl->mutex); +} + +void i915_request_add(struct i915_request *rq) +{ + struct intel_timeline * const tl = i915_request_timeline(rq); + + i915_request_add_locked(rq); + + intel_context_timeline_unlock(tl); }

static unsigned long local_clock_ns(unsigned int *cpu) diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h index bb48bd4605c03..29e3a37c300a7 100644 --- a/drivers/gpu/drm/i915/i915_request.h +++ b/drivers/gpu/drm/i915/i915_request.h @@ -425,6 +425,7 @@ int i915_request_await_deps(struct i915_request *rq, const struct i915_deps *dep int i915_request_await_execution(struct i915_request *rq, struct dma_fence *fence);

+void i915_request_add_locked(struct i915_request *rq); void i915_request_add(struct i915_request *rq);

bool __i915_request_submit(struct i915_request *request);

Currently, when we perform operations such as clearing or copying large blocks of memory, we generate multiple requests that are executed in a chain.

However, if one of these requests fails, we may not realize it unless it happens to be the last request in the chain. This is because errors are not properly propagated.

For this we need to keep propagating the chain of fence notification in order to always reach the final fence associated to the final request.

To address this issue, we need to ensure that the chain of fence notifications is always propagated so that we can reach the final fence associated with the last request. By doing so, we will be able to detect any memory operation failures and determine whether the memory is still invalid.

On copy and clear migration signal fences upon completion.

On copy and clear migration, signal fences upon request completion to ensure that we have a reliable perpetuation of the operation outcome.

Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration") Reported-by: Matthew Auld matthew.auld@intel.com Suggested-by: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Andi Shyti andi.shyti@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld matthew.auld@intel.com Acked-by: Nirmoy Das nirmoy.das@intel.com --- drivers/gpu/drm/i915/gt/intel_migrate.c | 51 +++++++++++++++++++------ 1 file changed, 39 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c b/drivers/gpu/drm/i915/gt/intel_migrate.c index 3f638f1987968..668c95af8cbcf 100644 --- a/drivers/gpu/drm/i915/gt/intel_migrate.c +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c @@ -742,13 +742,19 @@ intel_context_migrate_copy(struct intel_context *ce, dst_offset = 2 * CHUNK_SZ; }

+ /* + * While building the chain of requests, we need to ensure + * that no one can sneak into the timeline unnoticed. + */ + mutex_lock(&ce->timeline->mutex); + do { int len;

- rq = i915_request_create(ce); + rq = i915_request_create_locked(ce); if (IS_ERR(rq)) { err = PTR_ERR(rq); - goto out_ce; + break; }

if (deps) { @@ -878,10 +884,14 @@ intel_context_migrate_copy(struct intel_context *ce,

/* Arbitration is re-enabled between requests. */ out_rq: - if (*out) + i915_sw_fence_await(&rq->submit); + i915_request_get(rq); + i915_request_add_locked(rq); + if (*out) { + i915_sw_fence_complete(&(*out)->submit); i915_request_put(*out); - *out = i915_request_get(rq); - i915_request_add(rq); + } + *out = rq;

if (err) break; @@ -905,7 +915,10 @@ intel_context_migrate_copy(struct intel_context *ce, cond_resched(); } while (1);

-out_ce: + mutex_unlock(&ce->timeline->mutex); + + if (*out) + i915_sw_fence_complete(&(*out)->submit); return err; }

@@ -999,13 +1012,19 @@ intel_context_migrate_clear(struct intel_context *ce, if (HAS_64K_PAGES(i915) && is_lmem) offset = CHUNK_SZ;

+ /* + * While building the chain of requests, we need to ensure + * that no one can sneak into the timeline unnoticed. + */ + mutex_lock(&ce->timeline->mutex); + do { int len;

- rq = i915_request_create(ce); + rq = i915_request_create_locked(ce); if (IS_ERR(rq)) { err = PTR_ERR(rq); - goto out_ce; + break; }

if (deps) { @@ -1056,17 +1075,25 @@ intel_context_migrate_clear(struct intel_context *ce,

/* Arbitration is re-enabled between requests. */ out_rq: - if (*out) + i915_sw_fence_await(&rq->submit); + i915_request_get(rq); + i915_request_add_locked(rq); + if (*out) { + i915_sw_fence_complete(&(*out)->submit); i915_request_put(*out); - *out = i915_request_get(rq); - i915_request_add(rq); + } + *out = rq; + if (err || !it.sg || !sg_dma_len(it.sg)) break;

cond_resched(); } while (1);

-out_ce: + mutex_unlock(&ce->timeline->mutex); + + if (*out) + i915_sw_fence_complete(&(*out)->submit); return err; }

On 12.04.2023 13:33, Andi Shyti wrote:

Make version of the request creation that doesn't hold any lock.

Signed-off-by: Andi Shyti andi.shyti@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Nirmoy Das nirmoy.das@intel.com

---

drivers/gpu/drm/i915/i915_request.c | 38 +++++++++++++++++++++-------- drivers/gpu/drm/i915/i915_request.h | 2 ++ 2 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 630a732aaecca..58662360ac34e 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1028,15 +1028,11 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) return ERR_PTR(ret); } -struct i915_request * -i915_request_create(struct intel_context *ce) +static struct i915_request * +__i915_request_create_locked(struct intel_context *ce) {

• struct intel_timeline *tl = ce->timeline; struct i915_request *rq;

• struct intel_timeline *tl;
• tl = intel_context_timeline_lock(ce);
• if (IS_ERR(tl))

• return ERR_CAST(tl);
  

/* Move our oldest request to the slab-cache (if not in use!) */ rq = list_first_entry(&tl->requests, typeof(*rq), link); @@ -1046,16 +1042,38 @@ i915_request_create(struct intel_context *ce) intel_context_enter(ce); rq = __i915_request_create(ce, GFP_KERNEL); intel_context_exit(ce); /* active reference transferred to request */

• if (IS_ERR(rq))

• goto err_unlock;
  

• return rq;
  

/* Check that we do not interrupt ourselves with a new request */ rq->cookie = lockdep_pin_lock(&tl->mutex); return rq; +}

+struct i915_request * +i915_request_create_locked(struct intel_context *ce) +{

• intel_context_assert_timeline_is_locked(ce->timeline);
• return __i915_request_create_locked(ce);

+}

I wonder if we really need to have such granularity? Leaving only i915_request_create_locked and removing __i915_request_create_locked would simplify little bit the code, I guess the cost of calling intel_context_assert_timeline_is_locked twice sometimes is not big, or maybe it can be re-arranged, up to you.

Reviewed-by: Andrzej Hajda andrzej.hajda@intel.com

Regards Andrzej

+struct i915_request * +i915_request_create(struct intel_context *ce) +{

• struct i915_request *rq;
• struct intel_timeline *tl;
• tl = intel_context_timeline_lock(ce);
• if (IS_ERR(tl))

• return ERR_CAST(tl);
  

• rq = __i915_request_create_locked(ce);
• if (IS_ERR(rq))

• intel_context_timeline_unlock(tl);
  

-err_unlock:

• intel_context_timeline_unlock(tl); return rq; }

diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h index f5e1bb5e857aa..bb48bd4605c03 100644 --- a/drivers/gpu/drm/i915/i915_request.h +++ b/drivers/gpu/drm/i915/i915_request.h @@ -374,6 +374,8 @@ struct i915_request * __must_check __i915_request_create(struct intel_context *ce, gfp_t gfp); struct i915_request * __must_check i915_request_create(struct intel_context *ce); +struct i915_request * __must_check +i915_request_create_locked(struct intel_context *ce); void __i915_request_skip(struct i915_request *rq); bool i915_request_set_error_once(struct i915_request *rq, int error);

Hi Andrzej,

...

Make version of the request creation that doesn't hold any lock.

Signed-off-by: Andi Shyti andi.shyti@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Nirmoy Das nirmoy.das@intel.com

---

drivers/gpu/drm/i915/i915_request.c | 38 +++++++++++++++++++++-------- drivers/gpu/drm/i915/i915_request.h | 2 ++ 2 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 630a732aaecca..58662360ac34e 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1028,15 +1028,11 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) return ERR_PTR(ret); } -struct i915_request * -i915_request_create(struct intel_context *ce) +static struct i915_request * +__i915_request_create_locked(struct intel_context *ce) {

• struct intel_timeline *tl = ce->timeline; struct i915_request *rq;

• struct intel_timeline *tl;
• tl = intel_context_timeline_lock(ce);
• if (IS_ERR(tl))

• return ERR_CAST(tl);
  

  /* Move our oldest request to the slab-cache (if not in use!) */ rq = list_first_entry(&tl->requests, typeof(*rq), link);

@@ -1046,16 +1042,38 @@ i915_request_create(struct intel_context *ce) intel_context_enter(ce); rq = __i915_request_create(ce, GFP_KERNEL); intel_context_exit(ce); /* active reference transferred to request */

• if (IS_ERR(rq))

• goto err_unlock;
  

• return rq;
  

  /* Check that we do not interrupt ourselves with a new request */ rq->cookie = lockdep_pin_lock(&tl->mutex); return rq;

+}

+struct i915_request * +i915_request_create_locked(struct intel_context *ce) +{

• intel_context_assert_timeline_is_locked(ce->timeline);
• return __i915_request_create_locked(ce);

+}

I wonder if we really need to have such granularity? Leaving only i915_request_create_locked and removing __i915_request_create_locked would simplify little bit the code, I guess the cost of calling intel_context_assert_timeline_is_locked twice sometimes is not big, or maybe it can be re-arranged, up to you.

There is some usage of such granularity in patch 4. I am adding here the throttle on the timeline. I am adding it in the "_locked" version to avoid potential deadlocks coming from selftests (and from realworld?).

Here I'd love to have some comments from Chris and Matt.

I might still add this in the commit message:

"i915_request_create_locked() is now empty but will be used in later commits where a throttle on the ringspace will be executed to ensure exclusive ownership of the timeline."

Reviewed-by: Andrzej Hajda andrzej.hajda@intel.com

Thanks!

Andi

On 12/04/2023 12:33, Andi Shyti wrote:

Currently, when we perform operations such as clearing or copying large blocks of memory, we generate multiple requests that are executed in a chain.

However, if one of these requests fails, we may not realize it unless it happens to be the last request in the chain. This is because errors are not properly propagated.

For this we need to keep propagating the chain of fence notification in order to always reach the final fence associated to the final request.

To address this issue, we need to ensure that the chain of fence notifications is always propagated so that we can reach the final fence associated with the last request. By doing so, we will be able to detect any memory operation failures and determine whether the memory is still invalid.

Above two paragraphs seems to have redundancy in the message they convey.

On copy and clear migration signal fences upon completion.

On copy and clear migration, signal fences upon request completion to ensure that we have a reliable perpetuation of the operation outcome.

These two too. So I think commit message can be a bit polished.

Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration") Reported-by: Matthew Auld matthew.auld@intel.com Suggested-by: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Andi Shyti andi.shyti@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld matthew.auld@intel.com Acked-by: Nirmoy Das nirmoy.das@intel.com

---

drivers/gpu/drm/i915/gt/intel_migrate.c | 51 +++++++++++++++++++------ 1 file changed, 39 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c b/drivers/gpu/drm/i915/gt/intel_migrate.c index 3f638f1987968..668c95af8cbcf 100644 --- a/drivers/gpu/drm/i915/gt/intel_migrate.c +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c @@ -742,13 +742,19 @@ intel_context_migrate_copy(struct intel_context *ce, dst_offset = 2 * CHUNK_SZ; }

• /*

• * While building the chain of requests, we need to ensure
  

• * that no one can sneak into the timeline unnoticed.
  

• */
  

• mutex_lock(&ce->timeline->mutex);
• do { int len;

• rq = i915_request_create(ce);
  

• rq = i915_request_create_locked(ce);
  

  if (IS_ERR(rq)) { err = PTR_ERR(rq);

• 	goto out_ce;
  

• 	break;
  

  }

if (deps) { @@ -878,10 +884,14 @@ intel_context_migrate_copy(struct intel_context *ce, /* Arbitration is re-enabled between requests. */ out_rq:

• if (*out)
  

• i915_sw_fence_await(&rq->submit);
  

• i915_request_get(rq);
  

• i915_request_add_locked(rq);
  

• if (*out) {
  

• 	i915_sw_fence_complete(&(*out)->submit);
  i915_request_put(*out);
  

Could you help me understand this please. I have a few questions - first, what are the actual mechanics of fence error transfer here? I see the submit fence is being blocked until the next request is submitted - effectively previous request is only allowed to get on the hardware after the next one has been queued up. But I don't immediately see what that does in practice.

Second question relates to the need to hold the timeline mutex throughout. Presumably this is so two copy or migrate operations on the same context do not interleave, which can otherwise happen?

Would the error propagation be doable without the lock held by chaining on the previous request _completion_ fence? If so I am sure that would have a performance impact, because chunk by chunk would need a GPU<->CPU round trip to schedule. How much of an impact I don't know. Maybe enlarging CHUNK_SZ to compensate is an option?

Or if the perf hit would be bearable for stable backports only (much smaller patch) and then for tip we can do this full speed solution.

But yes, I would first want to understand the actual error propagation mechanism because sadly my working knowledge is a bit rusty.

• *out = i915_request_get(rq);
  

• i915_request_add(rq);
  

• }
  

• *out = rq;
  

if (err) break; @@ -905,7 +915,10 @@ intel_context_migrate_copy(struct intel_context *ce, cond_resched(); } while (1); -out_ce:

• mutex_unlock(&ce->timeline->mutex);
• if (*out)

• i915_sw_fence_complete(&(*out)->submit);
  

  return err; }

@@ -999,13 +1012,19 @@ intel_context_migrate_clear(struct intel_context *ce, if (HAS_64K_PAGES(i915) && is_lmem) offset = CHUNK_SZ;

• /*

• * While building the chain of requests, we need to ensure
  

• * that no one can sneak into the timeline unnoticed.
  

• */
  

• mutex_lock(&ce->timeline->mutex);
• do { int len;

• rq = i915_request_create(ce);
  

• rq = i915_request_create_locked(ce);
  

  if (IS_ERR(rq)) { err = PTR_ERR(rq);

• 	goto out_ce;
  

• 	break;
  

  }

if (deps) { @@ -1056,17 +1075,25 @@ intel_context_migrate_clear(struct intel_context *ce, /* Arbitration is re-enabled between requests. */ out_rq:

• if (*out)
  

• i915_sw_fence_await(&rq->submit);
  

• i915_request_get(rq);
  

• i915_request_add_locked(rq);
  

• if (*out) {
  

• 	i915_sw_fence_complete(&(*out)->submit);
  i915_request_put(*out);
  

• *out = i915_request_get(rq);
  

• i915_request_add(rq);
  

• }
  

• *out = rq;
  

Btw if all else fails perhaps these two blocks can be consolidated by something like __chain_requests(rq, out) and all these operations in it. Not sure how much would that save in the grand total.

Regards,

Tvrtko

• if (err || !it.sg || !sg_dma_len(it.sg)) break;

cond_resched(); } while (1); -out_ce:

• mutex_unlock(&ce->timeline->mutex);
• if (*out)

• i915_sw_fence_complete(&(*out)->submit);
  

  return err; }

Hi Tvrtko,

sorry for the very late reply, it's about time to bring this patch up.

On Thu, Apr 13, 2023 at 12:56:00PM +0100, Tvrtko Ursulin wrote:

On 12/04/2023 12:33, Andi Shyti wrote:

...

Currently, when we perform operations such as clearing or copying large blocks of memory, we generate multiple requests that are executed in a chain.

However, if one of these requests fails, we may not realize it unless it happens to be the last request in the chain. This is because errors are not properly propagated.

For this we need to keep propagating the chain of fence notification in order to always reach the final fence associated to the final request.

To address this issue, we need to ensure that the chain of fence notifications is always propagated so that we can reach the final fence associated with the last request. By doing so, we will be able to detect any memory operation failures and determine whether the memory is still invalid.

Above two paragraphs seems to have redundancy in the message they convey.

...

On copy and clear migration signal fences upon completion.

On copy and clear migration, signal fences upon request completion to ensure that we have a reliable perpetuation of the operation outcome.

These two too. So I think commit message can be a bit polished.

In my intent of being very explicative I might have exaggerated. I know that these kind of patches might bring some controversy.

I will review the commit.

...

Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration") Reported-by: Matthew Auld matthew.auld@intel.com Suggested-by: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Andi Shyti andi.shyti@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld matthew.auld@intel.com Acked-by: Nirmoy Das nirmoy.das@intel.com

---

drivers/gpu/drm/i915/gt/intel_migrate.c | 51 +++++++++++++++++++------ 1 file changed, 39 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c b/drivers/gpu/drm/i915/gt/intel_migrate.c index 3f638f1987968..668c95af8cbcf 100644 --- a/drivers/gpu/drm/i915/gt/intel_migrate.c +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c @@ -742,13 +742,19 @@ intel_context_migrate_copy(struct intel_context *ce, dst_offset = 2 * CHUNK_SZ; }

• /*

• * While building the chain of requests, we need to ensure
  

• * that no one can sneak into the timeline unnoticed.
  

• */
  

• mutex_lock(&ce->timeline->mutex);
• do { int len;

• rq = i915_request_create(ce);
  

• rq = i915_request_create_locked(ce);
  

  if (IS_ERR(rq)) { err = PTR_ERR(rq);

• 	goto out_ce;
  

• 	break;
  

  } if (deps) {

@@ -878,10 +884,14 @@ intel_context_migrate_copy(struct intel_context *ce, /* Arbitration is re-enabled between requests. */ out_rq:

• if (*out)
  

• i915_sw_fence_await(&rq->submit);
  

• i915_request_get(rq);
  

• i915_request_add_locked(rq);
  

• if (*out) {
  

• 	i915_sw_fence_complete(&(*out)->submit);
  i915_request_put(*out);
  

Could you help me understand this please. I have a few questions - first, what are the actual mechanics of fence error transfer here? I see the submit fence is being blocked until the next request is submitted - effectively previous request is only allowed to get on the hardware after the next one has been queued up. But I don't immediately see what that does in practice.

This is the basic of the error perpetuation. Without this serialization, for big operations like migrate and copy, we would only catch the error in the last rq.

Second question relates to the need to hold the timeline mutex throughout. Presumably this is so two copy or migrate operations on the same context do not interleave, which can otherwise happen?

Would the error propagation be doable without the lock held by chaining on the previous request _completion_ fence? If so I am sure that would have a performance impact, because chunk by chunk would need a GPU<->CPU round trip to schedule. How much of an impact I don't know. Maybe enlarging CHUNK_SZ to compensate is an option?

The need for a mutex lock comes from adding the throttle during request creation, which ensures no pending requests are being served.

I will copy paste from Chris review, which was missed in the mailing list:

Adding a large throttle before the mutex makes the race less likely, but to overcome that just increase the number of simultaneous clients fighting for ring space.

If we hold the lock while constructing the chain, no one else may inject themselves between links in our chain. If we do not, we may end up with

ABCDEFGHI ^head ^tail

Then in order for A to submit its next request it has to wait upon its previous request. But since we are holding the submit fence for A, it will not be executed until after we complete our submission. Boom.

Andi

Or if the perf hit would be bearable for stable backports only (much smaller patch) and then for tip we can do this full speed solution.

But yes, I would first want to understand the actual error propagation mechanism because sadly my working knowledge is a bit rusty.

...

• *out = i915_request_get(rq);
  

• i915_request_add(rq);
  

• }
  

• *out = rq;
  

  if (err) break;

@@ -905,7 +915,10 @@ intel_context_migrate_copy(struct intel_context *ce, cond_resched(); } while (1); -out_ce:

• mutex_unlock(&ce->timeline->mutex);
• if (*out)

• i915_sw_fence_complete(&(*out)->submit);
  

  return err; }

@@ -999,13 +1012,19 @@ intel_context_migrate_clear(struct intel_context *ce, if (HAS_64K_PAGES(i915) && is_lmem) offset = CHUNK_SZ;

• /*

• * While building the chain of requests, we need to ensure
  

• * that no one can sneak into the timeline unnoticed.
  

• */
  

• mutex_lock(&ce->timeline->mutex);
• do { int len;

• rq = i915_request_create(ce);
  

• rq = i915_request_create_locked(ce);
  

  if (IS_ERR(rq)) { err = PTR_ERR(rq);

• 	goto out_ce;
  

• 	break;
  

  } if (deps) {

@@ -1056,17 +1075,25 @@ intel_context_migrate_clear(struct intel_context *ce, /* Arbitration is re-enabled between requests. */ out_rq:

• if (*out)
  

• i915_sw_fence_await(&rq->submit);
  

• i915_request_get(rq);
  

• i915_request_add_locked(rq);
  

• if (*out) {
  

• 	i915_sw_fence_complete(&(*out)->submit);
  i915_request_put(*out);
  

• *out = i915_request_get(rq);
  

• i915_request_add(rq);
  

• }
  

• *out = rq;
  

Btw if all else fails perhaps these two blocks can be consolidated by something like __chain_requests(rq, out) and all these operations in it. Not sure how much would that save in the grand total.

Regards,

Tvrtko

...

• if (err || !it.sg || !sg_dma_len(it.sg)) break; cond_resched(); } while (1);

-out_ce:

• mutex_unlock(&ce->timeline->mutex);
• if (*out)

• i915_sw_fence_complete(&(*out)->submit);
  

  return err; }