From: "Hellstrom, Thomas" <thomas.hellstrom@intel.com>
To: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Vishwanathapura,
Niranjana" <niranjana.vishwanathapura@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>,
"Auld, Matthew" <matthew.auld@intel.com>,
"Vetter, Daniel" <daniel.vetter@intel.com>,
"christian.koenig@amd.com" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes
Date: Thu, 7 Jul 2022 13:11:13 +0000 [thread overview]
Message-ID: <d1c8cd2c44c07ebc7053f192100bf0ee5aa67140.camel@intel.com> (raw)
In-Reply-To: <20220701225055.8204-9-niranjana.vishwanathapura@intel.com>
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> For persistent (vm_bind) vmas of userptr BOs, handle the user
> page pinning by using the i915_gem_object_userptr_submit_init()
> /done() functions
>
> Signed-off-by: Niranjana Vishwanathapura
> <niranjana.vishwanathapura@intel.com>
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 67
> +++++++++++++++++++
> .../drm/i915/gem/i915_gem_vm_bind_object.c | 16 +++++
> drivers/gpu/drm/i915/gt/intel_gtt.c | 1 +
> drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
> 4 files changed, 85 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> index 2079f5ca9010..bf13dd6d642e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> @@ -22,6 +22,7 @@
> #include "i915_gem_vm_bind.h"
> #include "i915_trace.h"
>
> +#define __EXEC3_USERPTR_USED BIT_ULL(34)
> #define __EXEC3_HAS_PIN BIT_ULL(33)
> #define __EXEC3_ENGINE_PINNED BIT_ULL(32)
> #define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
> @@ -147,10 +148,36 @@ static void eb_scoop_unbound_vmas(struct
> i915_address_space *vm)
> spin_unlock(&vm->vm_rebind_lock);
> }
>
> +static int eb_lookup_persistent_userptr_vmas(struct i915_execbuffer
> *eb)
> +{
> + struct i915_address_space *vm = eb->context->vm;
> + struct i915_vma *last_vma = NULL;
> + struct i915_vma *vma;
> + int err;
> +
> + assert_vm_bind_held(vm);
> +
> + list_for_each_entry(vma, &vm->vm_bind_list, vm_bind_link) {
> + if (i915_gem_object_is_userptr(vma->obj)) {
> + err =
> i915_gem_object_userptr_submit_init(vma->obj);
> + if (err)
> + return err;
> +
> + last_vma = vma;
> + }
> + }
> +
Don't we need to loop also over non-private userptr objects?
> + if (last_vma)
> + eb->args->flags |= __EXEC3_USERPTR_USED;
> +
> + return 0;
> +}
> +
> static int eb_lookup_vmas(struct i915_execbuffer *eb)
> {
> unsigned int i, current_batch = 0;
> struct i915_vma *vma;
> + int err = 0;
>
> for (i = 0; i < eb->num_batches; i++) {
> vma = eb_find_vma(eb->context->vm, eb-
> >batch_addresses[i]);
> @@ -163,6 +190,10 @@ static int eb_lookup_vmas(struct i915_execbuffer
> *eb)
>
> eb_scoop_unbound_vmas(eb->context->vm);
>
> + err = eb_lookup_persistent_userptr_vmas(eb);
> + if (err)
> + return err;
> +
> return 0;
> }
>
> @@ -358,15 +389,51 @@ static void
> eb_persistent_vmas_move_to_active(struct i915_execbuffer *eb)
>
> static int eb_move_to_gpu(struct i915_execbuffer *eb)
> {
> + int err = 0, j;
> +
> assert_vm_bind_held(eb->context->vm);
> assert_vm_priv_held(eb->context->vm);
>
> eb_persistent_vmas_move_to_active(eb);
>
> +#ifdef CONFIG_MMU_NOTIFIER
> + if (!err && (eb->args->flags & __EXEC3_USERPTR_USED)) {
> + struct i915_vma *vma;
> +
> + assert_vm_bind_held(eb->context->vm);
> + assert_vm_priv_held(eb->context->vm);
> +
> + read_lock(&eb->i915->mm.notifier_lock);
> + list_for_each_entry(vma, &eb->context->vm-
> >vm_bind_list,
> + vm_bind_link) {
> + if (!i915_gem_object_is_userptr(vma->obj))
> + continue;
> +
> + err =
> i915_gem_object_userptr_submit_done(vma->obj);
> + if (err)
> + break;
> + }
> +
> + read_unlock(&eb->i915->mm.notifier_lock);
> + }
Since we don't loop over the vm_bound_list, there is a need to check
whether the rebind_list is empty here under the notifier_lock in read
mode, and in that case, restart from eb_lookup_vmas(). That might also
eliminate the need for the __EXEC3_USERPTR_USED flag?
That will also catch any objects that were evicted between
eb_lookup_vmas() where the rebind_list was last checked, and
i915_gem_vm_priv_lock(), which prohibits further eviction, but if we
want to catch these earlier (which I think is a good idea), we could
check that the rebind_list is indeed empty just after taking the
vm_priv_lock(), and if not, restart from eb_lookup_vmas().
> +#endif
> +
> + if (unlikely(err))
> + goto err_skip;
> +
> /* Unconditionally flush any chipset caches (for streaming
> writes). */
> intel_gt_chipset_flush(eb->gt);
>
> return 0;
> +
> +err_skip:
> + for_each_batch_create_order(eb, j) {
> + if (!eb->requests[j])
> + break;
> +
> + i915_request_set_error_once(eb->requests[j], err);
> + }
> + return err;
> }
>
> static int eb_request_submit(struct i915_execbuffer *eb,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> index 1a8efa83547f..cae282b91618 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> @@ -263,6 +263,12 @@ int i915_gem_vm_bind_obj(struct
> i915_address_space *vm,
> goto put_obj;
> }
>
> + if (i915_gem_object_is_userptr(obj)) {
> + ret = i915_gem_object_userptr_submit_init(obj);
> + if (ret)
> + goto put_obj;
> + }
> +
> ret = i915_gem_vm_bind_lock_interruptible(vm);
> if (ret)
> goto put_obj;
> @@ -295,6 +301,16 @@ int i915_gem_vm_bind_obj(struct
> i915_address_space *vm,
> /* Make it evictable */
> __i915_vma_unpin(vma);
>
> +#ifdef CONFIG_MMU_NOTIFIER
> + if (i915_gem_object_is_userptr(obj)) {
> + write_lock(&vm->i915->mm.notifier_lock);
Why do we need the lock in write mode here?
> + ret = i915_gem_object_userptr_submit_done(obj);
> + write_unlock(&vm->i915->mm.notifier_lock);
> + if (ret)
> + goto out_ww;
> + }
> +#endif
> +
> list_add_tail(&vma->vm_bind_link, &vm->vm_bound_list);
> i915_vm_bind_it_insert(vma, &vm->va);
> if (!obj->priv_root)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
> b/drivers/gpu/drm/i915/gt/intel_gtt.c
> index 55d5389b2c6c..4ab3bda644ff 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> @@ -295,6 +295,7 @@ void i915_address_space_init(struct
> i915_address_space *vm, int subclass)
> GEM_BUG_ON(IS_ERR(vm->root_obj));
> INIT_LIST_HEAD(&vm->vm_rebind_list);
> spin_lock_init(&vm->vm_rebind_lock);
> + INIT_LIST_HEAD(&vm->invalidate_link);
> }
>
> void *__px_vaddr(struct drm_i915_gem_object *p)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
> b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index fe5485c4a1cd..f9edf11c144f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> @@ -267,6 +267,7 @@ struct i915_address_space {
> struct list_head vm_bound_list;
> struct list_head vm_rebind_list;
> spinlock_t vm_rebind_lock; /* Protects vm_rebind_list */
> + struct list_head invalidate_link;
> /* va tree of persistent vmas */
> struct rb_root_cached va;
> struct list_head non_priv_vm_bind_list;
next prev parent reply other threads:[~2022-07-07 13:11 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-01 22:50 [Intel-gfx] [RFC 00/10] drm/i915/vm_bind: Add VM_BIND functionality Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 01/10] drm/i915/vm_bind: Introduce VM_BIND ioctl Niranjana Vishwanathapura
2022-07-05 9:59 ` Hellstrom, Thomas
2022-07-07 1:18 ` Andi Shyti
2022-07-07 5:06 ` Niranjana Vishwanathapura
2022-07-07 5:01 ` Niranjana Vishwanathapura
2022-07-07 7:32 ` Hellstrom, Thomas
2022-07-08 12:58 ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 02/10] drm/i915/vm_bind: Bind and unbind mappings Niranjana Vishwanathapura
2022-07-06 16:21 ` Thomas Hellström
2022-07-07 1:41 ` Andi Shyti
2022-07-07 5:48 ` Niranjana Vishwanathapura
2022-07-07 5:43 ` Niranjana Vishwanathapura
2022-07-07 8:14 ` Thomas Hellström
2022-07-08 12:57 ` Niranjana Vishwanathapura
2022-07-18 10:55 ` Tvrtko Ursulin
2022-07-26 5:07 ` Niranjana Vishwanathapura
2022-07-26 8:40 ` Tvrtko Ursulin
2022-07-01 22:50 ` [Intel-gfx] [RFC 03/10] drm/i915/vm_bind: Support private and shared BOs Niranjana Vishwanathapura
2022-07-07 10:31 ` Hellstrom, Thomas
2022-07-08 13:14 ` Niranjana Vishwanathapura
2022-07-08 13:43 ` Hellstrom, Thomas
2022-07-08 14:44 ` Hellstrom, Thomas
2022-07-09 20:13 ` Niranjana Vishwanathapura
2022-07-07 13:27 ` Christian König
2022-07-08 13:23 ` Niranjana Vishwanathapura
2022-07-08 17:32 ` Christian König
2022-07-09 20:14 ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 04/10] drm/i915/vm_bind: Add out fence support Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 05/10] drm/i915/vm_bind: Handle persistent vmas Niranjana Vishwanathapura
2022-07-04 17:05 ` Zeng, Oak
2022-07-05 9:20 ` Ramalingam C
2022-07-05 13:50 ` Zeng, Oak
2022-07-07 6:00 ` Niranjana Vishwanathapura
2022-07-07 11:27 ` Hellstrom, Thomas
2022-07-08 15:06 ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 06/10] drm/i915/vm_bind: Add I915_GEM_EXECBUFFER3 ioctl Niranjana Vishwanathapura
2022-07-07 14:41 ` Hellstrom, Thomas
2022-07-07 19:38 ` Andi Shyti
2022-07-08 12:22 ` Hellstrom, Thomas
2022-07-08 13:47 ` Niranjana Vishwanathapura
2022-07-08 14:37 ` Hellstrom, Thomas
2022-07-09 20:23 ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 07/10] drm/i915/vm_bind: Handle persistent vmas in execbuf3 Niranjana Vishwanathapura
2022-07-07 14:54 ` Hellstrom, Thomas
2022-07-08 12:44 ` Niranjana Vishwanathapura
2022-07-08 13:03 ` Hellstrom, Thomas
2022-07-09 20:25 ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes Niranjana Vishwanathapura
2022-07-07 13:11 ` Hellstrom, Thomas [this message]
2022-07-08 14:51 ` Niranjana Vishwanathapura
2022-07-08 15:20 ` Hellstrom, Thomas
2022-07-09 20:56 ` Niranjana Vishwanathapura
2022-07-08 12:17 ` Hellstrom, Thomas
2022-07-08 14:54 ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 09/10] drm/i915/vm_bind: Skip vma_lookup for persistent vmas Niranjana Vishwanathapura
2022-07-05 8:57 ` Thomas Hellström
2022-07-08 12:40 ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 10/10] drm/i915/vm_bind: Fix vm->vm_bind_mutex and vm->mutex nesting Niranjana Vishwanathapura
2022-07-05 8:40 ` Thomas Hellström
2022-07-06 16:33 ` Ramalingam C
2022-07-07 5:56 ` Niranjana Vishwanathapura
2022-07-01 23:19 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/vm_bind: Add VM_BIND functionality Patchwork
2022-07-01 23:19 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-07-01 23:40 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " 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=d1c8cd2c44c07ebc7053f192100bf0ee5aa67140.camel@intel.com \
--to=thomas.hellstrom@intel.com \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=niranjana.vishwanathapura@intel.com \
--cc=paulo.r.zanoni@intel.com \
/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