diff options
| author | Linus Torvalds <torvalds@linux-foundation.org> | 2026-10-02 12:17:24 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2026-10-02 12:17:24 -0700 |
| commit | 3f1fe48a36b0b6722dc3fd421d93512bac138e9a (patch) | |
| tree | b767d7f6e26bc64334d3f14f8422d187239dc45d /Documentation/gpu/amdgpu/process-isolation.rst | |
| download | linux-stable-3f1fe48a36b0b6722dc3fd421d93512bac138e9a.tar.gz linux-stable-3f1fe48a36b0b6722dc3fd421d93512bac138e9a.zip | |
Merge tag 'io_uring-7.3-20261002' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linuxgrafted
Pull io_uring fixes from Jens Axboe:
- Fix a task_work add use-after-free with SQPOLL.
The sqpoll thread could pop and complete the last request while
io_req_normal_work_add() was still looking at them after the mpscq
push.
Use the same approach as DEFER_TASKRUN to protect from that, holding
an RCU read lock across the add, and have exit wait for an RCU grace
period for SQPOLL rings as well.
- CQE32 ring fixes: correct the free entry check for 32b CQEs, zero the
big_cqe for aux CQEs, and only post the dummy skip CQE on CQE_MIXED
rings
- Mark the source filter table as COW when cloning bpf filters, so
registering another filter on the source doesn't modify the shared
table in place
- Initialize the task context before running the BPF loop
- Requeue zcrx multishot receives stopped by a local resource
- End a TX_TIMESTAMP multishot cmd when the CQ is full (lollipopkit)
* tag 'io_uring-7.3-20261002' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring: fix task_work add use-after-free with SQPOLL
io_uring/cmd_net: end TX_TIMESTAMP multishot when the CQ is full
io_uring/zcrx: requeue multishot receives stopped by a local resource
io_uring: initialize task context before running the BPF loop
io_uring: zero big_cqe for aux CQEs on CQE32 rings
io_uring: fix free entry check for 32b CQEs on CQE32 rings
io_uring: only post the dummy skip CQE on CQE_MIXED rings
io_uring/bpf_filter: mark source as COW when cloning filters
Diffstat (limited to 'Documentation/gpu/amdgpu/process-isolation.rst')
| -rw-r--r-- | Documentation/gpu/amdgpu/process-isolation.rst | 60 |
1 files changed, 60 insertions, 0 deletions
diff --git a/Documentation/gpu/amdgpu/process-isolation.rst b/Documentation/gpu/amdgpu/process-isolation.rst new file mode 100644 index 000000000..03c4288aa --- /dev/null +++ b/Documentation/gpu/amdgpu/process-isolation.rst @@ -0,0 +1,60 @@ +.. _amdgpu-process-isolation: +.. SPDX-License-Identifier: GPL-2.0 + +========================= + AMDGPU Process Isolation +========================= + +The AMDGPU driver includes a feature that enables automatic process isolation on the graphics engine. This feature serializes access to the graphics engine and adds a cleaner shader which clears the Local Data Store (LDS) and General Purpose Registers (GPRs) between jobs. All processes using the GPU, including both graphics and compute workloads, are serialized when this feature is enabled. On GPUs that support partitionable graphics engines, this feature can be enabled on a per-partition basis. + +In addition, there is an interface to manually run the cleaner shader when the use of the GPU is complete. This may be preferable in some use cases, such as a single-user system where the login manager triggers the cleaner shader when the user logs out. + +Process Isolation +================= + +The `run_cleaner_shader` and `enforce_isolation` sysfs interfaces allow users to manually execute the cleaner shader and control the process isolation feature, respectively. + +Partition Handling +------------------ + +The `enforce_isolation` file in sysfs can be used to enable process isolation and automatic shader cleanup between processes. On GPUs that support graphics engine partitioning, this can be enabled per partition. The partition and its current setting (0 disabled, 1 enabled) can be read from sysfs. On GPUs that do not support graphics engine partitioning, only a single partition will be present. Writing 1 to the partition position enables enforce isolation, writing 0 disables it. + +Example of enabling enforce isolation on a GPU with multiple partitions: + +.. code-block:: console + + $ echo 1 0 1 0 > /sys/class/drm/card0/device/enforce_isolation + $ cat /sys/class/drm/card0/device/enforce_isolation + 1 0 1 0 + +The output indicates that enforce isolation is enabled on zeroth and second partition and disabled on first and third partition. + +For devices with a single partition or those that do not support partitions, there will be only one element: + +.. code-block:: console + + $ echo 1 > /sys/class/drm/card0/device/enforce_isolation + $ cat /sys/class/drm/card0/device/enforce_isolation + 1 + +Cleaner Shader Execution +======================== + +The driver can trigger a cleaner shader to clean up the LDS and GPR state on the graphics engine. When process isolation is enabled, this happens automatically between processes. In addition, there is a sysfs file to manually trigger cleaner shader execution. + +To manually trigger the execution of the cleaner shader, write `0` to the `run_cleaner_shader` sysfs file: + +.. code-block:: console + + $ echo 0 > /sys/class/drm/card0/device/run_cleaner_shader + +For multi-partition devices, you can specify the partition index when triggering the cleaner shader: + +.. code-block:: console + + $ echo 0 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 0 + $ echo 1 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 1 + $ echo 2 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 2 + # ... and so on for each partition + +This command initiates the cleaner shader, which will run and complete before any new tasks are scheduled on the GPU. |
