diff options
| author | Karol Wachowski <karol.wachowski@linux.intel.com> | 2026-06-11 07:52:01 +0200 |
|---|---|---|
| committer | Karol Wachowski <karol.wachowski@linux.intel.com> | 2026-06-15 08:38:13 +0200 |
| commit | 85c9cc2d25f80534c1623621264018a655869cb2 (patch) | |
| tree | 30faa98ef70c8df89ed092beed4a3ec7ff2b2137 /tools/perf/scripts/python/bin | |
| parent | a56a73ec85c81c7e533bc249ff0fd996256053fd (diff) | |
accel/ivpu: Use threaded IRQ for IPC callback processing
Dispatching IPC callbacks from system_percpu_wq adds scheduling latency
that is neither bounded nor predictable, which hurts job completion
turnaround. Handle them from a threaded IRQ instead: the hard-IRQ
handler drains the IPC FIFO and wakes the thread, which runs the
callback consumers such as job-done processing.
Job resource teardown can trigger IOMMU unmapping and context teardown,
which is too slow to run from the IRQ thread. Defer it to a dedicated
WQ_UNBOUND | WQ_MEM_RECLAIM workqueue via a per-device lockless list.
UNBOUND keeps the long-running cleanup off the percpu workers and
MEM_RECLAIM guarantees forward progress because the work frees buffer
objects. The runtime PM reference taken at submission is released only
after cleanup completes, otherwise runtime suspend could race the
pending work and deadlock.
Because cleanup is now asynchronous, userspace that rapidly recycles
file descriptors or command queues can momentarily observe stale
per-context resources and fail with -EMFILE or -EBUSY. Flush the
cleanup work once and retry before giving up.
Reviewed-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Link: https://patch.msgid.link/20260611055201.948726-1-karol.wachowski@linux.intel.com
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions
