diff options
| author | Thomas Hellström <thomas.hellstrom@linux.intel.com> | 2025-09-08 12:12:39 +0200 |
|---|---|---|
| committer | Thomas Hellström <thomas.hellstrom@linux.intel.com> | 2025-09-10 09:16:01 +0200 |
| commit | c2ae94cf8cd86cd0a417865d194fb6c4cc81bfb1 (patch) | |
| tree | ecaecece99729e0268e5d73b01d287a531ecc31a /scripts/gdb/linux/vmalloc.py | |
| parent | 8f25e5abcbfb9cbcd923021774f2e785db3f7f55 (diff) | |
drm/xe: Convert the CPU fault handler for exhaustive eviction
The CPU fault handler may populate bos and migrate, and in doing
so might interfere with other tasks validating.
Rework the CPU fault handler completely into a fastpath
and a slowpath. The fastpath trylocks only the validation lock
in read-mode. If that fails, there's a fallback to the
slowpath, where we do a full validation transaction.
This mandates open-coding of bo locking, bo idling and
bo populating, but we still call into TTM for fault
finalizing.
v2:
- Rework the CPU fault handler to actually take part in
the exhaustive eviction scheme (Matthew Brost).
v3:
- Don't return anything but VM_FAULT_RETRY if we've dropped the
mmap_lock. Not even if a signal is pending.
- Rebase on gpu_madvise() and split out fault migration.
- Wait for idle after migration.
- Check whether the resource manager uses tts to determine
whether to map the tt or iomem.
- Add a number of asserts.
- Allow passing a ttm_operation_ctx to xe_bo_migrate() so that
it's possible to try non-blocking migration.
- Don't fall through to TTM on migration / population error
Instead remove the gfp_retry_mayfail in mode 2 where we
must succeed. (Matthew Brost)
v5:
- Don't allow faulting in the imported bo case (Matthew Brost)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthews Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250908101246.65025-7-thomas.hellstrom@linux.intel.com
Diffstat (limited to 'scripts/gdb/linux/vmalloc.py')
0 files changed, 0 insertions, 0 deletions
