- 26 Mar, 2021 4 commits
-
-
Daniel Vetter authored
Motivated by the pre-review process for i915 gem/gt features, but probably useful in general for complex stuff. v2: Add reminder to not forget userspace projects in the discussion (Simon, Jason) v3: Actually put this into a folder, so we have it all (.rst files and headers for kerneldoc) contained somewhere separate (Jason) Cc: Simon Ser <contact@emersion.fr> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Acked-by:
Jason Ekstrand <jason@jlekstrand.net> Acked-by:
Simon Ser <contact@emersion.fr> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325225859.1684116-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
We've discussed a bit how to get the gem/gt team better integrated and collaborate more with the wider community and agreed to the following: - all gem/gt patches are reviewed on dri-devel for now. That's overkill, but in the past there was definitely too little of that. - i915-gem folks are encouraged to cross review core patches from other teams - big features (especially uapi changes) need to be discussed in an rfc patch that documents the interface and big picture design, before we get lost in the details of the code - Also a rough TODO (can be refined as we go ofc) to get gem/gt back on track, like we've e.g. done with DAL/DC to get that in shape. v2: - add dma_fence annotations (Dave) - tasklet helpers (Jani on irc) There was also a discussion about moving these into gitlab issues, or gitlab issues as additional discussion place at least. For now it's just the TODO file Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Acked-by:
-
Tvrtko Ursulin authored
Module parameter is added (request_timeout_ms) to allow configuring the default request/fence expiry. Default value is inherited from CONFIG_DRM_I915_REQUEST_TIMEOUT. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Tvrtko Ursulin authored
A new Kconfig option CONFIG_DRM_I915_REQUEST_TIMEOUT is added, defaulting to 20s, and this timeout is applied to all users contexts using the previously added watchdog facility. Result of this is that any user submission will simply fail after this timeout, either causing a reset (for non-preemptable), or incomplete results. This can have an effect that workloads which used to work fine will suddenly start failing. Even workloads comprised of short batches but in long dependency chains can be terminated. And because of lack of agreement on usefulness and safety of fence error propagation this partial execution can be invisible to userspace even if it is "listening" to returned fence status. Another interaction is with hangcheck where care needs to be taken timeout is not set lower or close to three times the heartbeat interval. Otherwise a hang in any application can cause complete termination of all submissions from unrelated clients. Any users modifying the per engine heartbeat intervals therefore need to be aware of this potential denial of service to avoid inadvertently enabling it. Given all this I am personally not convinced the scheme is a good idea. Intuitively it feels object importers would be better positioned to enforce the time they are willing to wait for something to complete. v2: * Improved commit message and Kconfig text. * Pull in some helper code from patch which got dropped. v3: * Bump timeout to 20s to see if it helps Tigerlake. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
- 25 Mar, 2021 5 commits
-
-
Tvrtko Ursulin authored
Prepares the plumbing for setting request/fence expiration time. All code is put in place but is never activated due yet missing ability to actually configure the timer. Outline of the basic operation: A timer is started when request is ready for execution. If the request completes (retires) before the timer fires, timer is cancelled and nothing further happens. If the timer fires request is added to a lockless list and worker queued. Purpose of this is twofold: a) It allows request cancellation from a more friendly context and b) coalesces multiple expirations into a single event of consuming the list. Worker locklessly consumes the list of expired requests and cancels them all using previous added i915_request_cancel(). Associated timeout value is stored in rq->context.watchdog.timeout_us. v2: * Log expiration. v3: * Include more information about user timeline in the log message. v4: * Remove obsolete comment and fix formatting. (Matt) Signed-off-by:
-
Tvrtko Ursulin authored
With the watchdog cancelling requests asynchronously to preempt-to-busy we need to relax one assert making it apply only to requests not in error. v2: * Check against the correct request! v3: * Simplify the check to avoid the question of when to sample the fence error vs sentinel bit. Signed-off-by:
-
Tvrtko Ursulin authored
Disallow sentinel requests follow previous sentinels to make request cancellation work better when faced with a chain of requests which have all been marked as in error. Because in cases where we end up with a stream of cancelled requests we want to turn off request coalescing so they each will get individually skipped by the execlists_schedule_in (which is called per ELSP port, not per request). Signed-off-by:
-
Chris Wilson authored
Currently, we cancel outstanding requests within a context when the context is closed. We may also want to cancel individual requests using the same graceful preemption mechanism. v2 (Tvrtko): * Cancel waiters carefully considering no timeline lock and RCU. * Fixed selftests. v3 (Tvrtko): * Remove error propagation to waiters for now. v4 (Tvrtko): * Rebase for extracted i915_request_active_engine. (Matt) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Tvrtko Ursulin authored
Move active engine lookup to exported i915_request_active_engine. Signed-off-by:
-
- 24 Mar, 2021 31 commits
-
-
Maarten Lankhorst authored
We get a lockdep splat when the reset mutex is held, because it can be taken from fence_wait. This conflicts with the mmu notifier we have, because we recurse between reset mutex and mmap lock -> mmu notifier. Remove this recursion by calling revoke_mmaps before taking the lock. The reset code still needs fixing, as taking mmap locks during reset is not allowed. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> [danvet: Add FIXME.] Signed-off-by:
-
Maarten Lankhorst authored
Instead of force unbinding and rebinding every time, we try to check if our notifier seqcount is still correct when pages are bound. This way we only rebind userptr when we need to, and prevent stalls. Changes since v1: - Missing mutex_unlock, reported by kbuild. Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
With all callers and selftests fixed to use ww locking, we can now finally remove this lock. Signed-off-by:
-
Maarten Lankhorst authored
We need to lock the global gtt dma_resv, use i915_vm_lock_objects to handle this correctly. Add ww handling for this where required. Add the object lock around unpin/put pages, and use the unlocked versions of pin_pages and pin_map where required. Signed-off-by:
-
Maarten Lankhorst authored
Same as other tests, use pin_map_unlocked. Signed-off-by:
-
Maarten Lankhorst authored
Use the unlocked variants for pin_map and pin_pages, and add lock around unpinning/putting pages. Signed-off-by:
-
Maarten Lankhorst authored
Straightforward conversion by using unlocked versions. Signed-off-by:
-
Maarten Lankhorst authored
We can no longer call intel_timeline_pin with a null argument, so add a ww loop that locks the backing object. Signed-off-by:
-
Maarten Lankhorst authored
Use unlocked versions when the ww lock is not held. Signed-off-by:
-
Maarten Lankhorst authored
Use pin_map_unlocked when we're not holding locks. Signed-off-by:
-
Maarten Lankhorst authored
Convert normal functions to unlocked versions where needed. Signed-off-by:
-
Maarten Lankhorst authored
Convert a few calls to use the unlocked versions. Signed-off-by:
-
Maarten Lankhorst authored
Only needs to convert a single call to the unlocked version. Signed-off-by:
-
Maarten Lankhorst authored
igt_emit_store_dw needs to use the unlocked version, as it's not holding a lock. This fixes igt_gpu_fill_dw() which is used by some other selftests. Signed-off-by:
-
Maarten Lankhorst authored
Use some unlocked versions where we're not holding the ww lock. Signed-off-by:
-
Maarten Lankhorst authored
Convert a single pin_pages call to use the unlocked version. Signed-off-by:
-
Maarten Lankhorst authored
Ensure we hold the lock around put_pages, and use the unlocked wrappers for pinning pages and mappings. Signed-off-by:
-
Maarten Lankhorst authored
Also quite simple, a single call needs to use the unlocked version. Signed-off-by:
-
Maarten Lankhorst authored
Use pin_pages_unlocked() where we don't have a lock. Signed-off-by:
-
Maarten Lankhorst authored
Straightforward conversion, just convert a bunch of calls to unlocked versions. Signed-off-by:
-
Maarten Lankhorst authored
Straightforward conversion, just convert a bunch of calls to unlocked versions. Signed-off-by:
-
Maarten Lankhorst authored
Straightforward conversion, just convert a bunch of calls to unlocked versions. Signed-off-by:
-
Maarten Lankhorst authored
Straightforward conversion, just convert a bunch of calls to unlocked versions. Signed-off-by:
-
Maarten Lankhorst authored
We may create page table objects on the fly, but we may need to wait with the ww lock held. Instead of waiting on a freed obj lock, ensure we have the same lock for each object to keep -EDEADLK working. This ensures that i915_vma_pin_ww can lock the page tables when required. Signed-off-by:
-
Maarten Lankhorst authored
Quick fix, just use the unlocked version. Signed-off-by:
-
Maarten Lankhorst authored
Because of the long lifetime of the mapping, we cannot wrap this in a simple limited ww lock. Just use the unlocked version of pin_map, because we'll likely release the mapping a lot later, in a different thread. Signed-off-by:
-
Maarten Lankhorst authored
vmap is using pin_pages, but needs to use ww locking, add pin_pages_unlocked to correctly lock the mapping. Also add ww locking to begin/end cpu access. Changes since v1: - Fix i915_gem_map_dma_buf by using pin_pages_unlocked(). Signed-off-by:
-
Maarten Lankhorst authored
In the ucode functions, the calls are done before userspace runs, when debugging using debugfs, or when creating semi-permanent mappings; we can safely use the unlocked versions that does the ww dance for us. Because there is no pin_pages_unlocked yet, add it as convenience function. This removes possible lockdep splats about missing resv lock for ucode. Signed-off-by:
-
Maarten Lankhorst authored
We need to lock a few more objects, some temporarily, add ww lock where needed. Signed-off-by:
-
Maarten Lankhorst authored
i915_gem_object_pin_map potentially needs a ww context, so ensure we have one we can revoke. Signed-off-by:
-
Maarten Lankhorst authored
By default, we assume that it's called inside igt_create_request to keep existing selftests working, but allow for manual pinning when passing a ww context. Signed-off-by:
-
