From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: intel-xe@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Subject: [RFC PATCH 0/3] Use a dma_resv wound-wait transaction API for drm_exec
Date: Fri, 5 Jun 2026 13:26:57 +0200 [thread overview]
Message-ID: <20260605112700.181040-1-thomas.hellstrom@linux.intel.com> (raw)
The forward outlook of drm_exec is to be a genuine drm_exec helper
rather than a generic wound-wait transaction helper. Earlier attempts
to introduce exhaustive eviction within TTM using drm_exec have
been forced to extend drm_exec with modes that aren't of interest fo
a drm_exec helper, like eviction mode locking, snapshots, trylocks etc.
This series introduces dma_resv_txn, a subsystem-agnostic wound-wait
transaction layer for any objects that embed or reference a dma_resv.
Participant types register an ops vtable supplying callbacks to reach the
dma_resv and drop the object reference; the transaction layer handles all
lock ordering, wound-wait arbitration, and retry control.
drm_exec is then rebuilt as a thin wrapper on top, retaining its existing
API without changes to existing callers. The dma_resv code suggested
here also follows the previous drm_exec implementation closely with
the same design choices.
Possible use-cases may be ttm_object refcounting for eviction,
Additional eviction modes as described above, a dma_buf_map() functionality
passing a ww transaction locking context (drm_exec would've been a layering
violation), embedding resvs in GPU vm objects etc.
A live kunit benchmark for the drm_exec locking path is included.
It should be mentioned that this could be placed on an even lower level
(kernel/locking), but that would probably require potential other users
first and also a proper non-allocating trylock functionality.
Also tried an approach where object structures were allocated individually
using a kmem_cache and put on a linked list. However, the benchmark
showed a substantial performance hit compared to the pre-allocated
array approach that was originally used indrm_exec.
Thomas Hellström (3):
dma-buf: Add generic dma_resv wound-wait transaction API
drm/exec: Rebuild drm_exec on top of dma_resv_txn
drm/xe/tests: Add drm_exec locking benchmark kunit test
drivers/dma-buf/Makefile | 2 +-
drivers/dma-buf/dma-resv-txn.c | 300 +++++++++++++++++++
drivers/gpu/drm/drm_exec.c | 203 ++-----------
drivers/gpu/drm/xe/tests/Makefile | 3 +-
drivers/gpu/drm/xe/tests/xe_drm_exec_kunit.c | 130 ++++++++
drivers/gpu/drm/xe/tests/xe_live_test_mod.c | 2 +
drivers/gpu/drm/xe/xe_bo.c | 3 +
include/drm/drm_exec.h | 161 +++-------
include/linux/dma-resv-txn.h | 223 ++++++++++++++
9 files changed, 731 insertions(+), 296 deletions(-)
create mode 100644 drivers/dma-buf/dma-resv-txn.c
create mode 100644 drivers/gpu/drm/xe/tests/xe_drm_exec_kunit.c
create mode 100644 include/linux/dma-resv-txn.h
--
2.54.0
next reply other threads:[~2026-06-05 11:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 11:26 Thomas Hellström [this message]
2026-06-05 11:26 ` [RFC PATCH] dma-buf: Add generic dma_resv wound-wait transaction API Thomas Hellström
2026-06-05 11:26 ` [RFC PATCH] drm/exec: Rebuild drm_exec on top of dma_resv_txn Thomas Hellström
2026-06-05 11:27 ` [RFC PATCH] drm/xe/tests: Add drm_exec locking benchmark kunit test Thomas Hellström
2026-06-05 12:16 ` ✗ CI.checkpatch: warning for " Patchwork
2026-06-05 12:18 ` ✓ CI.KUnit: success " Patchwork
2026-06-05 13:13 ` ✓ Xe.CI.BAT: " Patchwork
2026-06-05 23:49 ` ✓ Xe.CI.FULL: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260605112700.181040-1-thomas.hellstrom@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox