[Intel-gfx] WIP glance towards struct_mutex removal
Chris Wilson
chris at chris-wilson.co.uk
Fri Jun 14 07:09:44 UTC 2019
This series is still under development, getting the coordination right
for async vma (having just make i915_vma refcounted, I need to actually
prevent the refcycles and fixup good old userspace in ggtt,
vma->open_count for everyone incl. gem_vm_ops).
[PATCH 01/39] drm/i915: Discard some redundant cache domain flushes
[PATCH 02/39] drm/i915: Refine i915_reset.lock_map
[PATCH 03/39] drm/i915: Avoid tainting i915_gem_park() with
[PATCH 04/39] drm/i915: Enable refcount debugging for default debug
Endless/qos patches:
[PATCH 05/39] drm/i915: Keep contexts pinned until after the next
[PATCH 06/39] drm/i915: Stop retiring along engine
[PATCH 07/39] drm/i915: Replace engine->timeline with a plain list
[PATCH 08/39] drm/i915: Flush the execution-callbacks on retiring
[PATCH 09/39] drm/i915/execlists: Preempt-to-busy
[PATCH 10/39] drm/i915/execlists: Minimalistic timeslicing
[PATCH 11/39] drm/i915/execlists: Force preemption
Remove struct_mutex from i915_actve:
[PATCH 12/39] dma-fence: Propagate errors to dma-fence-array
[PATCH 13/39] dma-fence: Report the composite sync_file status
[PATCH 14/39] dma-fence: Refactor signaling for manual invocation
[PATCH 15/39] dma-fence: Always execute signal callbacks
[PATCH 16/39] drm/i915: Execute signal callbacks from no-op
[PATCH 17/39] drm/i915: Make the semaphore saturation mask global
[PATCH 18/39] drm/i915: Throw away the active object retirement
[PATCH 19/39] drm/i915: Provide an i915_active.acquire callback
[PATCH 20/39] drm/i915: Push the i915_active.retire into a worker
[PATCH 21/39] drm/i915/overlay: Switch to using i915_active tracking
[PATCH 22/39] drm/i915: Forgo last_fence active request tracking
[PATCH 23/39] drm/i915: Extract intel_frontbuffer active tracking
[PATCH 24/39] drm/i915: Coordinate i915_active with its own mutex
Up to this point, we should be solid; and removing struct_mutex around
i915_active is a major milestone as it was one of the two remaining
requirements for holding struct_mutex across request construction. In
principle, now you just need the timeline mutex, which is taken and
pinned by i915_request_create. (The remaining problem is making
retirement only require the timeline mutex as well.)
Remove struct_mutex from i915_address_space:
[PATCH 25/39] drm/i915: Track ggtt fence reservations under its own
[PATCH 26/39] drm/i915: Only track bound elements of the GTT
[PATCH 27/39] drm/i915: Explicitly cleanup initial_plane_config
[PATCH 28/39] initial-plane-vma
[PATCH 29/39] drm/i915: Make i915_vma track its own kref
[PATCH 30/39] drm/i915: Propagate fence errors
[PATCH 31/39] drm/i915: Allow page pinning to be in the background
[PATCH 32/39] drm/i915: Allow vma binding to occur asynchronously
[PATCH 33/39] revoke-fence
[PATCH 34/39] drm/i915: Use vm->mutex for serialising GTT insertion
This is quite close. Major refleak in i915_vma aka finishing touches in
converting it to be refcounted, and I need to take a pass over the async
vma to force the worker even for ggtt if we need to allocate pages (e.g.
rotation, remap, partial).
At this point, we drop the struct_mutex pretty much everywhere
internally. And should be free to start doing interesting things from
within obj->mm workers.
async get_pages:
[PATCH 35/39] drm/i915: Pin pages before waiting
[PATCH 36/39] drm/i915: Use reservation_object to coordinate userptr
One such example. Broken across rebases and needs fixing up: async
get-pages.
Remove struct_mutex for i915_requests:
[PATCH 37/39] drm/i915: Use forced preemptions in preference over
[PATCH 38/39] drm/i915: Remove logical HW ID
[PATCH 39/39] active-rings
And to complete the picture to remove struct_mutex around i915_request,
we need to be able to retire under the timeline alone. With that
inplace, we can drop struct_mutex. This presumptiously removes it from
GEM_EXECBUFFER_IOCTL, but that's a little bit premature as there are
still auxiliaries that need their own locks but is the ultimate proof.
Please look over and flag any more issues you can spot.
-Chris
More information about the Intel-gfx
mailing list