[2/3] drm/i915: Drop inspection of execbuf flags during evict

Commit Message

Chris Wilson Nov. 6, 2019, 3:48 p.m. UTC

With the goal of removing the serialisation from around execbuf, we will
no longer have the privilege of there being a single execbuf in flight
at any time and so will only be able to inspect the user's flags within
the carefully controlled execbuf context. i915_gem_evict_for_node() is
the only user outside of execbuf that currently peeks at the flag to
convert an overlapping softpinned request from ENOSPC to EINVAL. Retract
this nicety and only report ENOSPC if the location is in current use,
either due to this execbuf or another.

Signed-off-by: Chris Wilson <[e-mail]>
Cc: Joonas Lahtinen <[e-mail]>
Reviewed-by: Joonas Lahtinen <[e-mail]>
---
 drivers/gpu/drm/i915/i915_gem_evict.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

Comments

Daniel Vetter Nov. 8, 2019, 9:54 a.m. UTC | #1

On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson <[e-mail]> wrote:
>
> With the goal of removing the serialisation from around execbuf, we will
> no longer have the privilege of there being a single execbuf in flight
> at any time and so will only be able to inspect the user's flags within
> the carefully controlled execbuf context. i915_gem_evict_for_node() is
> the only user outside of execbuf that currently peeks at the flag to
> convert an overlapping softpinned request from ENOSPC to EINVAL. Retract
> this nicety and only report ENOSPC if the location is in current use,
> either due to this execbuf or another.
>
> Signed-off-by: Chris Wilson <[e-mail]>
> Cc: Joonas Lahtinen <[e-mail]>
> Reviewed-by: Joonas Lahtinen <[e-mail]>

Same reasons as for patch 3, I don't think we have to do this at all.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_gem_evict.c | 15 ++++++---------
>  1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 7e62c310290f..1395018c657a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -292,7 +292,8 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
>                 GEM_BUG_ON(!drm_mm_node_allocated(node));
>                 vma = container_of(node, typeof(*vma), node);
>
> -               /* If we are using coloring to insert guard pages between
> +               /*
> +                * If we are using coloring to insert guard pages between
>                  * different cache domains within the address space, we have
>                  * to check whether the objects on either side of our range
>                  * abutt and conflict. If they are in conflict, then we evict
> @@ -309,22 +310,18 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
>                         }
>                 }
>
> -               if (flags & PIN_NONBLOCK &&
> -                   (i915_vma_is_pinned(vma) || i915_vma_is_active(vma))) {
> +               if (i915_vma_is_pinned(vma)) {
>                         ret = -ENOSPC;
>                         break;
>                 }
>
> -               /* Overlap of objects in the same batch? */
> -               if (i915_vma_is_pinned(vma)) {
> +               if (flags & PIN_NONBLOCK && i915_vma_is_active(vma)) {
>                         ret = -ENOSPC;
> -                       if (vma->exec_flags &&
> -                           *vma->exec_flags & EXEC_OBJECT_PINNED)
> -                               ret = -EINVAL;
>                         break;
>                 }
>
> -               /* Never show fear in the face of dragons!
> +               /*
> +                * Never show fear in the face of dragons!
>                  *
>                  * We cannot directly remove this node from within this
>                  * iterator and as with i915_gem_evict_something() we employ
> --
> 2.24.0
>
> _______________________________________________
> Intel-gfx mailing list
> [e-mail]
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Chris Wilson Nov. 8, 2019, 10:11 a.m. UTC | #2

Quoting Daniel Vetter (2019-11-08 09:54:42)
> On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson <[e-mail]> wrote:
> >
> > With the goal of removing the serialisation from around execbuf, we will
> > no longer have the privilege of there being a single execbuf in flight
> > at any time and so will only be able to inspect the user's flags within
> > the carefully controlled execbuf context. i915_gem_evict_for_node() is
> > the only user outside of execbuf that currently peeks at the flag to
> > convert an overlapping softpinned request from ENOSPC to EINVAL. Retract
> > this nicety and only report ENOSPC if the location is in current use,
> > either due to this execbuf or another.
> >
> > Signed-off-by: Chris Wilson <[e-mail]>
> > Cc: Joonas Lahtinen <[e-mail]>
> > Reviewed-by: Joonas Lahtinen <[e-mail]>
> 
> Same reasons as for patch 3, I don't think we have to do this at all.

This is already undefined behaviour. That field is protected by
struct_mutex and being evaluated outside of that lock.
-Chris

Daniel Vetter Nov. 8, 2019, 10:20 a.m. UTC | #3

On Fri, Nov 8, 2019 at 11:11 AM Chris Wilson <[e-mail]> wrote:
> Quoting Daniel Vetter (2019-11-08 09:54:42)
> > On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson <[e-mail]> wrote:
> > >
> > > With the goal of removing the serialisation from around execbuf, we will
> > > no longer have the privilege of there being a single execbuf in flight
> > > at any time and so will only be able to inspect the user's flags within
> > > the carefully controlled execbuf context. i915_gem_evict_for_node() is
> > > the only user outside of execbuf that currently peeks at the flag to
> > > convert an overlapping softpinned request from ENOSPC to EINVAL. Retract
> > > this nicety and only report ENOSPC if the location is in current use,
> > > either due to this execbuf or another.
> > >
> > > Signed-off-by: Chris Wilson <[e-mail]>
> > > Cc: Joonas Lahtinen <[e-mail]>
> > > Reviewed-by: Joonas Lahtinen <[e-mail]>
> >
> > Same reasons as for patch 3, I don't think we have to do this at all.
>
> This is already undefined behaviour. That field is protected by
> struct_mutex and being evaluated outside of that lock.

If this can be called on objects involved in execbuf, without
struct_mutex, then we already have a correctness problem of vma space
(which is super tight on old platforms and rather much required to be
well-managed because of that) being lost because concurrent threads
thrash it instead of forming an orderly queue. And if that's not the
case, and they do form an orderly queue, then there's no problem since
even the as-needed-only orderly queue provided by ww_mutex will then
be enough locking to keep this working.

Aside: Yeah I think we need to re-add struct_mutex to the gtt fault
path, the temporary pinning in there could easily starve execbuf on
platforms where batches run in ggtt. Maybe also some other areas where
we lost struct_mutex around temporary vma->pin_count elevations.
-Daniel

Chris Wilson Nov. 8, 2019, 10:40 a.m. UTC | #4

Quoting Daniel Vetter (2019-11-08 10:20:23)
> On Fri, Nov 8, 2019 at 11:11 AM Chris Wilson <[e-mail]> wrote:
> > Quoting Daniel Vetter (2019-11-08 09:54:42)
> > > On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson <[e-mail]> wrote:
> > > >
> > > > With the goal of removing the serialisation from around execbuf, we will
> > > > no longer have the privilege of there being a single execbuf in flight
> > > > at any time and so will only be able to inspect the user's flags within
> > > > the carefully controlled execbuf context. i915_gem_evict_for_node() is
> > > > the only user outside of execbuf that currently peeks at the flag to
> > > > convert an overlapping softpinned request from ENOSPC to EINVAL. Retract
> > > > this nicety and only report ENOSPC if the location is in current use,
> > > > either due to this execbuf or another.
> > > >
> > > > Signed-off-by: Chris Wilson <[e-mail]>
> > > > Cc: Joonas Lahtinen <[e-mail]>
> > > > Reviewed-by: Joonas Lahtinen <[e-mail]>
> > >
> > > Same reasons as for patch 3, I don't think we have to do this at all.
> >
> > This is already undefined behaviour. That field is protected by
> > struct_mutex and being evaluated outside of that lock.
> 
> If this can be called on objects involved in execbuf, without
> struct_mutex, then we already have a correctness problem of vma space
> (which is super tight on old platforms and rather much required to be
> well-managed because of that) being lost because concurrent threads
> thrash it instead of forming an orderly queue. And if that's not the
> case, and they do form an orderly queue, then there's no problem since
> even the as-needed-only orderly queue provided by ww_mutex will then
> be enough locking to keep this working.

It doesn't get called on those objects, those objects may just be
neighbouring and being inspected for potential eviction candidates. The
lists themselves are protected by their mutex, it's just the contention
over the pin_count.
 
> Aside: Yeah I think we need to re-add struct_mutex to the gtt fault
> path, the temporary pinning in there could easily starve execbuf on
> platforms where batches run in ggtt. Maybe also some other areas where
> we lost struct_mutex around temporary vma->pin_count elevations.

That's where we are going next; not with struct_mutex but fenced access
to reservations to replace the temporary (not HW access) pinning.
-Chris

Daniel Vetter Nov. 8, 2019, 4:06 p.m. UTC | #5

On Fri, Nov 8, 2019 at 11:40 AM Chris Wilson <[e-mail]> wrote:
>
> Quoting Daniel Vetter (2019-11-08 10:20:23)
> > On Fri, Nov 8, 2019 at 11:11 AM Chris Wilson <[e-mail]> wrote:
> > > Quoting Daniel Vetter (2019-11-08 09:54:42)
> > > > On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson <[e-mail]> wrote:
> > > > >
> > > > > With the goal of removing the serialisation from around execbuf, we will
> > > > > no longer have the privilege of there being a single execbuf in flight
> > > > > at any time and so will only be able to inspect the user's flags within
> > > > > the carefully controlled execbuf context. i915_gem_evict_for_node() is
> > > > > the only user outside of execbuf that currently peeks at the flag to
> > > > > convert an overlapping softpinned request from ENOSPC to EINVAL. Retract
> > > > > this nicety and only report ENOSPC if the location is in current use,
> > > > > either due to this execbuf or another.
> > > > >
> > > > > Signed-off-by: Chris Wilson <[e-mail]>
> > > > > Cc: Joonas Lahtinen <[e-mail]>
> > > > > Reviewed-by: Joonas Lahtinen <[e-mail]>
> > > >
> > > > Same reasons as for patch 3, I don't think we have to do this at all.
> > >
> > > This is already undefined behaviour. That field is protected by
> > > struct_mutex and being evaluated outside of that lock.
> >
> > If this can be called on objects involved in execbuf, without
> > struct_mutex, then we already have a correctness problem of vma space
> > (which is super tight on old platforms and rather much required to be
> > well-managed because of that) being lost because concurrent threads
> > thrash it instead of forming an orderly queue. And if that's not the
> > case, and they do form an orderly queue, then there's no problem since
> > even the as-needed-only orderly queue provided by ww_mutex will then
> > be enough locking to keep this working.
>
> It doesn't get called on those objects, those objects may just be
> neighbouring and being inspected for potential eviction candidates. The
> lists themselves are protected by their mutex, it's just the contention
> over the pin_count.

Hm yeah in a per-bo locked future world this won't work. But today it
should be either vm->mutex or dev->struct_mutex, not already broken?

Otoh in the per-bo locked future we only care about conflicts with our
own execbuf, which means we could check whether the object belongs to
our batch (very easy by looking at dma_resv->lock.ctx, ttm does that
in a few places), and only do the check in that case. So could retain
full uapi semantics here without additional effort (we need to have
these locks anway, at least in any kind of execbuf slowpath where the
bo aren't all mapped when we start out). So still not understanding
(even with the "it's other bo" overlook rectified) why we have to drop
this?

> > Aside: Yeah I think we need to re-add struct_mutex to the gtt fault
> > path, the temporary pinning in there could easily starve execbuf on
> > platforms where batches run in ggtt. Maybe also some other areas where
> > we lost struct_mutex around temporary vma->pin_count elevations.
>
> That's where we are going next; not with struct_mutex but fenced access
> to reservations to replace the temporary (not HW access) pinning.

fenced as in dma_fence or dma_resv_lock?

Also if we indeed have an issue with lost elevated pin_counts now I
think we shouldn't ship 5.5 with that, and reapply the duct tape until
it's fixed for good.
-Daniel

Patch

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c
index 7e62c310290f..1395018c657a 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -292,7 +292,8 @@  int i915_gem_evict_for_node(struct i915_address_space *vm,
 		GEM_BUG_ON(!drm_mm_node_allocated(node));
 		vma = container_of(node, typeof(*vma), node);
 
-		/* If we are using coloring to insert guard pages between
+		/*
+		 * If we are using coloring to insert guard pages between
 		 * different cache domains within the address space, we have
 		 * to check whether the objects on either side of our range
 		 * abutt and conflict. If they are in conflict, then we evict
@@ -309,22 +310,18 @@  int i915_gem_evict_for_node(struct i915_address_space *vm,
 			}
 		}
 
-		if (flags & PIN_NONBLOCK &&
-		    (i915_vma_is_pinned(vma) || i915_vma_is_active(vma))) {
+		if (i915_vma_is_pinned(vma)) {
 			ret = -ENOSPC;
 			break;
 		}
 
-		/* Overlap of objects in the same batch? */
-		if (i915_vma_is_pinned(vma)) {
+		if (flags & PIN_NONBLOCK && i915_vma_is_active(vma)) {
 			ret = -ENOSPC;
-			if (vma->exec_flags &&
-			    *vma->exec_flags & EXEC_OBJECT_PINNED)
-				ret = -EINVAL;
 			break;
 		}
 
-		/* Never show fear in the face of dragons!
+		/*
+		 * Never show fear in the face of dragons!
 		 *
 		 * We cannot directly remove this node from within this
 		 * iterator and as with i915_gem_evict_something() we employ