On Fri, 14 Jun 2019 at 08:11, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
>
> Serialising insertion into each of the global GTT and ppGTT accounts for
> a large chunk of the current struct_mutex serialisation requireemnts.
> (Note that it is not just the drm_mm / gtt management itself being
> serialised, but the pin count and various flags.) Previously, the main
> blocker for replacing this mutex was the reset handing, but with the
> advent of "lockless" resets, we can freely take the vm->mutex and block
> waiting for the GPU (without fear of deadlock if the GPU hangs). We also
> proscribe allocations underneath vm->mutex, allowing us to take the
> mutex inside the shrinker, avoiding the recursive struct_mutex we
> previously used.
>
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> ---
[snip]
> @@ -248,16 +248,6 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> goto err_rpm;
> }
>
> - ret = i915_mutex_lock_interruptible(dev);
> - if (ret)
> - goto err_reset;
> -
> - /* Access to snoopable pages through the GTT is incoherent. */
> - if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(i915)) {
> - ret = -EFAULT;
> - goto err_unlock;
> - }
Intentional? Perhaps harder to enforce now?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
