summaryrefslogtreecommitdiffstats
path: root/sys/dev/pci/drm/amd/amdgpu/amdgpu_object.c
diff options
context:
space:
mode:
authordlg <dlg@openbsd.org>2020-06-07 23:23:30 +0000
committerdlg <dlg@openbsd.org>2020-06-07 23:23:30 +0000
commitba6141230e521e0e88295f6eff6b83b7b2c89b38 (patch)
tree8ae2a26cd0b274e8afd0027bc6a3445bf8526210 /sys/dev/pci/drm/amd/amdgpu/amdgpu_object.c
parentSkip probing cbus(4/luna88k) and xp(4/luna88k) in RAMDISK kernel, they (diff)
downloadwireguard-openbsd-ba6141230e521e0e88295f6eff6b83b7b2c89b38.tar.xz
wireguard-openbsd-ba6141230e521e0e88295f6eff6b83b7b2c89b38.zip
add support for running taskq_barrier from a task inside the taskq.
this is required for an upcoming drm update, where the linux workqueue api that supports this is mapped to our taskq api. this main way taskqs support that is to have the taskq worker threads record thir curproc on the taskq, so taskq_barrier calls can iterate over that list looking for their own curproc. if a barriers curproc is in the list, it must be running inside the taskq, and should pretend that it's a barrier task. this also supports concurrent barrier calls by having the taskq recognise the situation and have the barriers work together rather than deadlocking. they end up trying to share the work of getting the barrier tasks onto the workers. once all the workers (or in tq barriers) have rendezvoused the barrier calls unwind, and the last one out lets the other barriers and barrier tasks return. all this barrier logic is implemented in the barrier code, it takes the existing multiworker handling out of the actual taskq loop. thanks to jsg@ for testing this and previous versions of the diff. ok visa@ kettenis@
Diffstat (limited to 'sys/dev/pci/drm/amd/amdgpu/amdgpu_object.c')
0 files changed, 0 insertions, 0 deletions