All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.