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
Subject: Re: [PATCH 1/3] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns
Date: Tue, 5 Apr 2016 13:05:05 +0100	[thread overview]
Message-ID: <5703A9F1.80805@linux.intel.com> (raw)
In-Reply-To: <1459703647-25795-1-git-send-email-chris@chris-wilson.co.uk>


On 03/04/16 18:14, Chris Wilson wrote:
> In order to ensure that all invalidations are completed before the
> operation returns to userspace (i.e. before the mmap() syscall returns)
> we need to flush the outstanding operations. To this end, we submit all
> the per-object invalidation work to a private workqueue and then flush
> the workqueue at the end of the function. We are allowed to block inside
> invalidate_range_start, and struct_mutex is the inner lock so the worker
> is not hiding any lock inversions. The advantage of using the workqueue
> over direct calling of cancel_userptr() is that it allows us to
> parallelise the potential waits and unpinning of large objects.

There was no direct calling, but running it from a shared wq which is 
now private, per task->mm.

But it sounds so obvious now that the mmu notifier needs to wait for 
cancel_userptr workers to complete that I wonder how we missed that 
until now.

I would also spell out the two new bits explicitly in the commit: 
waiting for workers and waiting on rendering.

With some more description for the latter - why it is needed? 
i915_vma_unbind would be doing a flavour of waiting already.

Otherwise I did not find any issues with the code itself, just these 
high level questions.

Regards,

Tvrtko

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94699
> Testcase: igt/gem_userptr_blits/sync-unmap-cycles
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Michał Winiarski <michal.winiarski@intel.com>
> ---
>   drivers/gpu/drm/i915/i915_gem_userptr.c | 48 ++++++++++++++++++++++++++++++++-
>   1 file changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 291a9393493d..92b39186b05a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -49,6 +49,7 @@ struct i915_mmu_notifier {
>   	struct hlist_node node;
>   	struct mmu_notifier mn;
>   	struct rb_root objects;
> +	struct workqueue_struct *wq;
>   };
>
>   struct i915_mmu_object {
> @@ -60,6 +61,40 @@ struct i915_mmu_object {
>   	bool attached;
>   };
>
> +static void wait_rendering(struct drm_i915_gem_object *obj)
> +{
> +	struct drm_device *dev = obj->base.dev;
> +	struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
> +	unsigned reset_counter;
> +	int i, n;
> +
> +	if (!obj->active)
> +		return;
> +
> +	n = 0;
> +	for (i = 0; i < I915_NUM_ENGINES; i++) {
> +		struct drm_i915_gem_request *req;
> +
> +		req = obj->last_read_req[i];
> +		if (req == NULL)
> +			continue;
> +
> +		requests[n++] = i915_gem_request_reference(req);
> +	}
> +
> +	reset_counter = atomic_read(&to_i915(dev)->gpu_error.reset_counter);
> +	mutex_unlock(&dev->struct_mutex);
> +
> +	for (i = 0; i < n; i++)
> +		__i915_wait_request(requests[i], reset_counter, false,
> +				    NULL, NULL);
> +
> +	mutex_lock(&dev->struct_mutex);
> +
> +	for (i = 0; i < n; i++)
> +		i915_gem_request_unreference(requests[i]);
> +}
> +
>   static void cancel_userptr(struct work_struct *work)
>   {
>   	struct i915_mmu_object *mo = container_of(work, typeof(*mo), work);
> @@ -75,6 +110,8 @@ static void cancel_userptr(struct work_struct *work)
>   		struct i915_vma *vma, *tmp;
>   		bool was_interruptible;
>
> +		wait_rendering(obj);
> +
>   		was_interruptible = dev_priv->mm.interruptible;
>   		dev_priv->mm.interruptible = false;
>
> @@ -140,7 +177,7 @@ static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
>   		 */
>   		mo = container_of(it, struct i915_mmu_object, it);
>   		if (kref_get_unless_zero(&mo->obj->base.refcount))
> -			schedule_work(&mo->work);
> +			queue_work(mn->wq, &mo->work);
>
>   		list_add(&mo->link, &cancelled);
>   		it = interval_tree_iter_next(it, start, end);
> @@ -148,6 +185,8 @@ static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
>   	list_for_each_entry(mo, &cancelled, link)
>   		del_object(mo);
>   	spin_unlock(&mn->lock);
> +
> +	flush_workqueue(mn->wq);
>   }
>
>   static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
> @@ -167,10 +206,16 @@ i915_mmu_notifier_create(struct mm_struct *mm)
>   	spin_lock_init(&mn->lock);
>   	mn->mn.ops = &i915_gem_userptr_notifier;
>   	mn->objects = RB_ROOT;
> +	mn->wq = alloc_workqueue("i915-userptr-release", WQ_UNBOUND, 0);
> +	if (mn->wq == NULL) {
> +		kfree(mn);
> +		return ERR_PTR(-ENOMEM);
> +	}
>
>   	 /* Protected by mmap_sem (write-lock) */
>   	ret = __mmu_notifier_register(&mn->mn, mm);
>   	if (ret) {
> +		destroy_workqueue(mn->wq);
>   		kfree(mn);
>   		return ERR_PTR(ret);
>   	}
> @@ -256,6 +301,7 @@ i915_mmu_notifier_free(struct i915_mmu_notifier *mn,
>   		return;
>
>   	mmu_notifier_unregister(&mn->mn, mm);
> +	destroy_workqueue(mn->wq);
>   	kfree(mn);
>   }
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2016-04-05 12:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-03 17:14 [PATCH 1/3] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns Chris Wilson
2016-04-03 17:14 ` [PATCH 2/3] drm/i915/userptr: Hold mmref whilst calling get-user-pages Chris Wilson
2016-04-03 21:11   ` Michał Winiarski
2016-04-03 21:11     ` Michał Winiarski
2016-04-05 12:22   ` [Intel-gfx] " Tvrtko Ursulin
2016-04-03 17:14 ` [PATCH 3/3] drm/i915: Store i915 pointer for userptr i915_mm_struct Chris Wilson
2016-04-03 21:12   ` Michał Winiarski
2016-04-04  6:27 ` ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns Patchwork
2016-04-05 12:05 ` Tvrtko Ursulin [this message]
2016-04-05 12:34   ` [PATCH 1/3] " Chris Wilson
2016-04-05 13:59 ` [PATCH v2 " Chris Wilson
2016-04-05 14:00   ` [PATCH v2 2/3] drm/i915/userptr: Hold mmref whilst calling get-user-pages Chris Wilson
2016-04-05 14:00     ` Chris Wilson
2016-04-05 14:00   ` [PATCH v2 3/3] drm/i915/userptr: Store i915 backpointer for i915_mm_struct Chris Wilson
2016-04-05 15:27   ` [PATCH v2 1/3] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns Tvrtko Ursulin
2016-04-05 16:57 ` ✗ Fi.CI.BAT: failure for series starting with [v2,3/3] drm/i915/userptr: Store i915 backpointer for i915_mm_struct (rev4) 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=5703A9F1.80805@linux.intel.com \
    --to=tvrtko.ursulin@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.