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

From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/3] drm/i915: Drop inspection of execbuf flags during evict
Date: Fri, 8 Nov 2019 11:20:23 +0100	[thread overview]
Message-ID: <CAKMK7uE5tCFHALPQbYJkJdC0iVXMeO3ut37MrT02f4e6aveEhQ@mail.gmail.com> (raw)
In-Reply-To: <157320790442.9461.15671764737191591137@skylake-alporthouse-com>

On Fri, Nov 8, 2019 at 11:11 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Daniel Vetter (2019-11-08 09:54:42)
> > On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson <chris@chris-wilson.co.uk> 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 <chris@chris-wilson.co.uk>
> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> >
> > 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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx