Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

drm/atomic-helper: replace use of system_unbound_wq with system_dfl_wq

Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.

This lack of consistency cannot be addressed without refactoring the API.

system_unbound_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.

Adding system_dfl_wq to encourage its use when unbound work should be used.

The old system_unbound_wq will be kept for a few release cycles.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20251030162043.292468-2-marco.crivellari@suse.com

authored by

Marco Crivellari and committed by
Thomas Zimmermann
b351df4b 9d757669

+3 -3
+3 -3
drivers/gpu/drm/drm_atomic_helper.c
··· 2301 2301 * current layout. 2302 2302 * 2303 2303 * NOTE: Commit work has multiple phases, first hardware commit, then 2304 - * cleanup. We want them to overlap, hence need system_unbound_wq to 2304 + * cleanup. We want them to overlap, hence need system_dfl_wq to 2305 2305 * make sure work items don't artificially stall on each another. 2306 2306 */ 2307 2307 2308 2308 drm_atomic_state_get(state); 2309 2309 if (nonblock) 2310 - queue_work(system_unbound_wq, &state->commit_work); 2310 + queue_work(system_dfl_wq, &state->commit_work); 2311 2311 else 2312 2312 commit_tail(state); 2313 2313 ··· 2340 2340 * 2341 2341 * Asynchronous workers need to have sufficient parallelism to be able to run 2342 2342 * different atomic commits on different CRTCs in parallel. The simplest way to 2343 - * achieve this is by running them on the &system_unbound_wq work queue. Note 2343 + * achieve this is by running them on the &system_dfl_wq work queue. Note 2344 2344 * that drivers are not required to split up atomic commits and run an 2345 2345 * individual commit in parallel - userspace is supposed to do that if it cares. 2346 2346 * But it might be beneficial to do that for modesets, since those necessarily