From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 8/8] drm/i915/gem: Avoid gem_context->mutex for simple vma lookup
Date: Mon, 23 Mar 2020 10:38:06 +0000 [thread overview]
Message-ID: <9c23a5be-7baf-2196-e4ef-446caf9d709b@linux.intel.com> (raw)
In-Reply-To: <20200323092841.22240-8-chris@chris-wilson.co.uk>
On 23/03/2020 09:28, Chris Wilson wrote:
> As we store the handle lookup inside a radix tree, we do not need the
> gem_context->mutex except until we need to insert our lookup into the
> common radix tree. This takes a small bit of rearranging to ensure that
> the lut we insert into the tree is ready prior to actually inserting it
> (as soon as it is exposed via the radixtree, it is visible to any other
> submission).
>
> v2: For brownie points, remove the goto spaghetti.
> v3: Tighten up the closed-handle checks.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 136 +++++++++++-------
> 1 file changed, 87 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index e80c6f613feb..c643eec4dca0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -481,7 +481,7 @@ eb_add_vma(struct i915_execbuffer *eb,
>
> GEM_BUG_ON(i915_vma_is_closed(vma));
>
> - ev->vma = i915_vma_get(vma);
> + ev->vma = vma;
> ev->exec = entry;
> ev->flags = entry->flags;
>
> @@ -728,77 +728,117 @@ static int eb_select_context(struct i915_execbuffer *eb)
> return 0;
> }
>
> -static int eb_lookup_vmas(struct i915_execbuffer *eb)
> +static int __eb_add_lut(struct i915_execbuffer *eb,
> + u32 handle, struct i915_vma *vma)
> {
> - struct radix_tree_root *handles_vma = &eb->gem_context->handles_vma;
> - struct drm_i915_gem_object *obj;
> - unsigned int i, batch;
> + struct i915_gem_context *ctx = eb->gem_context;
> + struct i915_lut_handle *lut;
> int err;
>
> - if (unlikely(i915_gem_context_is_closed(eb->gem_context)))
> - return -ENOENT;
> + lut = i915_lut_handle_alloc();
> + if (unlikely(!lut))
> + return -ENOMEM;
>
> - INIT_LIST_HEAD(&eb->relocs);
> - INIT_LIST_HEAD(&eb->unbound);
> + i915_vma_get(vma);
> + if (!atomic_fetch_inc(&vma->open_count))
> + i915_vma_reopen(vma);
> + lut->handle = handle;
> + lut->ctx = ctx;
> +
> + /* Check that the context hasn't been closed in the meantime */
> + err = -EINTR;
> + if (!mutex_lock_interruptible(&ctx->mutex)) {
> + err = -ENOENT;
> + if (likely(!i915_gem_context_is_closed(ctx)))
> + err = radix_tree_insert(&ctx->handles_vma, handle, vma);
> + if (err == 0) { /* And nor has this handle */
> + struct drm_i915_gem_object *obj = vma->obj;
> +
> + i915_gem_object_lock(obj);
> + if (idr_find(&eb->file->object_idr, handle) == obj) {
> + list_add(&lut->obj_link, &obj->lut_list);
> + } else {
> + radix_tree_delete(&ctx->handles_vma, handle);
> + err = -ENOENT;
> + }
> + i915_gem_object_unlock(obj);
> + }
> + mutex_unlock(&ctx->mutex);
> + }
> + if (unlikely(err))
> + goto err;
>
> - batch = eb_batch_index(eb);
> + return 0;
>
> - for (i = 0; i < eb->buffer_count; i++) {
> - u32 handle = eb->exec[i].handle;
> - struct i915_lut_handle *lut;
> +err:
> + atomic_dec(&vma->open_count);
> + i915_vma_put(vma);
> + i915_lut_handle_free(lut);
> + return err;
> +}
> +
> +static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32 handle)
> +{
> + do {
> + struct drm_i915_gem_object *obj;
> struct i915_vma *vma;
> + int err;
>
> - vma = radix_tree_lookup(handles_vma, handle);
> + rcu_read_lock();
> + vma = radix_tree_lookup(&eb->gem_context->handles_vma, handle);
> + if (likely(vma))
> + vma = i915_vma_tryget(vma);
> + rcu_read_unlock();
> if (likely(vma))
> - goto add_vma;
> + return vma;
>
> obj = i915_gem_object_lookup(eb->file, handle);
> - if (unlikely(!obj)) {
> - err = -ENOENT;
> - goto err_vma;
> - }
> + if (unlikely(!obj))
> + return ERR_PTR(-ENOENT);
>
> vma = i915_vma_instance(obj, eb->context->vm, NULL);
> if (IS_ERR(vma)) {
> - err = PTR_ERR(vma);
> - goto err_obj;
> + i915_gem_object_put(obj);
> + return vma;
> }
>
> - lut = i915_lut_handle_alloc();
> - if (unlikely(!lut)) {
> - err = -ENOMEM;
> - goto err_obj;
> - }
> + err = __eb_add_lut(eb, handle, vma);
> + if (likely(!err))
> + return vma;
>
> - err = radix_tree_insert(handles_vma, handle, vma);
> - if (unlikely(err)) {
> - i915_lut_handle_free(lut);
> - goto err_obj;
> - }
> + i915_gem_object_put(obj);
> + if (err != -EEXIST)
> + return ERR_PTR(err);
> + } while (1);
> +}
>
> - /* transfer ref to lut */
> - if (!atomic_fetch_inc(&vma->open_count))
> - i915_vma_reopen(vma);
> - lut->handle = handle;
> - lut->ctx = eb->gem_context;
> +static int eb_lookup_vmas(struct i915_execbuffer *eb)
> +{
> + unsigned int batch = eb_batch_index(eb);
> + unsigned int i;
> + int err = 0;
>
> - i915_gem_object_lock(obj);
> - list_add(&lut->obj_link, &obj->lut_list);
> - i915_gem_object_unlock(obj);
> + INIT_LIST_HEAD(&eb->relocs);
> + INIT_LIST_HEAD(&eb->unbound);
> +
> + for (i = 0; i < eb->buffer_count; i++) {
> + struct i915_vma *vma;
> +
> + vma = eb_lookup_vma(eb, eb->exec[i].handle);
> + if (IS_ERR(vma)) {
> + err = PTR_ERR(vma);
> + break;
> + }
>
> -add_vma:
> err = eb_validate_vma(eb, &eb->exec[i], vma);
> - if (unlikely(err))
> - goto err_vma;
> + if (unlikely(err)) {
> + i915_vma_put(vma);
> + break;
> + }
>
> eb_add_vma(eb, i, batch, vma);
> }
>
> - return 0;
> -
> -err_obj:
> - i915_gem_object_put(obj);
> -err_vma:
> eb->vma[i].vma = NULL;
> return err;
> }
> @@ -1494,9 +1534,7 @@ static int eb_relocate(struct i915_execbuffer *eb)
> {
> int err;
>
> - mutex_lock(&eb->gem_context->mutex);
> err = eb_lookup_vmas(eb);
> - mutex_unlock(&eb->gem_context->mutex);
> if (err)
> return err;
>
>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-03-23 10:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 9:28 [Intel-gfx] [PATCH 1/8] drm/i915/gt: Mark timeline->cacheline as destroyed after rcu grace period Chris Wilson
2020-03-23 9:28 ` [Intel-gfx] [PATCH 2/8] drm/i915: Avoid live-lock with i915_vma_parked() Chris Wilson
2020-03-23 10:09 ` Tvrtko Ursulin
2020-03-23 9:28 ` [Intel-gfx] [PATCH 3/8] drm/i915: Extend intel_wakeref to support delayed puts Chris Wilson
2020-03-23 10:13 ` Tvrtko Ursulin
2020-03-23 10:32 ` [Intel-gfx] [PATCH] " Chris Wilson
2020-03-23 12:24 ` Tvrtko Ursulin
2020-03-23 9:28 ` [Intel-gfx] [PATCH 4/8] drm/i915/gt: Delay release of engine-pm after last retirement Chris Wilson
2020-03-23 10:14 ` Tvrtko Ursulin
2020-03-23 9:28 ` [Intel-gfx] [PATCH 5/8] drm/i915: Rely on direct submission to the queue Chris Wilson
2020-03-23 10:29 ` Tvrtko Ursulin
2020-03-23 9:28 ` [Intel-gfx] [PATCH 6/8] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission Chris Wilson
2020-03-23 9:28 ` [Intel-gfx] [PATCH 7/8] drm/i915: Immediately execute the fenced work Chris Wilson
2020-03-23 10:37 ` Tvrtko Ursulin
2020-03-23 10:46 ` Chris Wilson
2020-03-24 16:13 ` Tvrtko Ursulin
2020-03-24 16:19 ` Chris Wilson
2020-03-23 11:04 ` [Intel-gfx] [PATCH] " Chris Wilson
2020-03-23 9:28 ` [Intel-gfx] [PATCH 8/8] drm/i915/gem: Avoid gem_context->mutex for simple vma lookup Chris Wilson
2020-03-23 10:38 ` Tvrtko Ursulin [this message]
2020-03-23 9:43 ` [Intel-gfx] [PATCH 1/8] drm/i915/gt: Mark timeline->cacheline as destroyed after rcu grace period Matthew Auld
2020-03-23 13:06 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/8] drm/i915/gt: Mark timeline->cacheline as destroyed after rcu grace period (rev3) 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=9c23a5be-7baf-2196-e4ef-446caf9d709b@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox