Re: [RFC v6.1 2/3] workqueue: Add support for real-time workers

[Tejun Heo <tj@kernel.org>]

Hello, Tvrtko.

On Mon, Oct 19, 2026 at 11:02:08AM +0100, Tvrtko Ursulin wrote:
> > apply_workqueue_attrs() is unrestricted, so a caller can hand a WQ_RT wq the
> > attrs from alloc_workqueue_attrs() and turn it into a normal non-strict wq
> > while the flag stays set. Maybe apply_wqattrs_prepare() should force prio
> > and affinity for WQ_RT instead of restricting only the sysfs side?
>
> I am not entirely sure about this one. It could be done in
> apply_wqattrs_prepare(), but it would end up redundant on the sysfs
> path. Because currently there are two paths:
...
> Am I missing something?

The missing one is apply_workqueue_attrs() called directly with attrs from
alloc_workqueue_attrs(), which is what padata_setup_cpumasks() does for
its own wq. Forcing prio and affinity in apply_wqattrs_prepare() covers
all the paths in one place. Being redundant on the sysfs path is fine.

> > alloc_ordered_workqueue() with WQ_RT passes this and ends up with a single
> > pool spanning all CPUs because ordered wqs use dfl_pwq everywhere, while the
> > doc and sysfs say strict per-CPU. Should __WQ_ORDERED be rejected too? The
> > nested ifs can also be a single condition.
>
> Not sure - Tejun what is your guidance here? Is this purely an
> implementation challenge because conceptually it should work, no?

Yeah, the priority part would work. It's just that an ordered wq has a
single pwq for all CPUs, so the per-CPU affinity can't apply. Let's reject
__WQ_ORDERED for now and allow it when there's a user.

> P.S. The nested ifs could be a single condition but I wanted to mimic
> the existing style so it looks nicer:
...
> I can change if desired.

Your call. A single condition would read fine too.

> > The three stores check WQ_RT and return -EINVAL while nice goes read-only
> > through is_visible below. Can all four go through
> > wq_sysfs_unbound_group_visible() returning 0444 for WQ_RT? That drops the
> > three store checks.
...
> Could do that if it would be acceptable for root to be still able to
> write to them - Tejun?

Root can't write to them. sysfs sets KERNFS_ROOT_EXTRA_OPEN_PERM_CHECK, so
kernfs_fop_open() fails a write open of a file without a write bit even
with CAP_DAC_OVERRIDE. Can you make nice, affinity_scope and
affinity_strict read-only through is_visible? cpumask can stay writable
as narrowing where the RT workers run doesn't break anything.

> > Can we keep printing nice for non-RT pools? prio=120 is the internal
> > encoding, sysfs and the pool dumps print nice, and the example output in
> > workqueue.rst would go stale. prog['RT_PRIORITY'] would match the rest of
> > the file too.
>
> We probably could if we wanted to. Tejun?
>
> Complication would be having to hardcode some priority conversion
> helpers into the script.

Yeah, let's keep nice. It's just prio - DEFAULT_PRIO and hardcoding 120 in
the script is fine.

> > One more thing which isn't in the diff. The rescuer of a WQ_RT |
> > WQ_MEM_RECLAIM wq, which is what panthor-drm-rt is, still runs at nice -20,
> > so under memory pressure the RT wq's work items run as CFS. Should
> > rescuer_thread() use sched_set_fifo_low() for WQ_RT?
>
> I did not think we should care much about latency when under severe
> memory pressure. It should be enough to guarantee forward progress and
> the latency restores back to normal once memory pressure stabilises.

Agreed.

Thanks.

--
tejun