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

[Tvrtko Ursulin]

On 29/09/2026 01:00, Tejun Heo wrote:
Hello,

On Wed, Sep 23, 2026 at 05:12:50PM +0100, Tvrtko Ursulin wrote:
For use cases such as the DRM scheduler submitting work to the GPU on
behalf of low latency userspace applications, where latter have sufficient
privileges to have had successfully obtained realtime Vulkan global
priority, competing with random background CPU load can create large
latency spikes which gets in the way of a smooth user experience.

panthor's group_priority_permit() also allows realtime groups for DRM
master without CAP_SYS_NICE. What's the usage model there? Should DRM
master be enough to get RT workers?

Usage model is one active compositor per device with the logind 
orchestrating on switch. So I'd say yes, it makes sense to allow the 
compositor RT. I shall improve the commit text to mention this.

@@ -374,8 +374,9 @@ enum wq_flags {
        WQ_FREEZABLE            = 1 << 2, /* freeze during suspend */
        WQ_MEM_RECLAIM          = 1 << 3, /* may be used for memory reclaim */
        WQ_HIGHPRI              = 1 << 4, /* high priority */
-       WQ_CPU_INTENSIVE        = 1 << 5, /* cpu intensive workqueue */
-       WQ_SYSFS                = 1 << 6, /* visible in sysfs, see 
workqueue_sysfs_register() */
+       WQ_RTPRI                = 1 << 5, /* real-time priority, valid only 
with WQ_UNBOUND */
+       WQ_CPU_INTENSIVE        = 1 << 6, /* cpu intensive workqueue */
+       WQ_SYSFS                = 1 << 7, /* visible in sysfs, see 
workqueue_sysfs_register() */

Can we name it just WQ_RT? Also, I think WQ_RT is closer to WQ_BH. We can
reorder the flags later if that helps but for now can you just put it in an
empty slot?

Sure, I thought it makes sense to group the related features together 
but if you prefer a smaller diff I will do that.


@@ -127,6 +127,7 @@ enum wq_internal_consts {
         */
        RESCUER_NICE_LEVEL      = MIN_NICE,
        HIGHPRI_NICE_LEVEL      = MIN_NICE,
+       RTPRI_NICE_LEVEL        = MIN_NICE - 1,

Can we match the scheduler's representation instead by replacing
attrs->nice with attrs->prio which uses the same encoding as p->prio?
Normal pools would be NICE_TO_PRIO(nice) and WQ_RT pools would be in the RT
range. create_worker() would then do:

        if (rt_prio(pool->attrs->prio))
                sched_set_fifo_low(worker->task);
        else
                set_user_nice(worker->task, PRIO_TO_NICE(pool->attrs->prio));

Ack.

@@ -7606,7 +7626,10 @@ static ssize_t nice_show(struct device *dev, struct 
device_attribute *attr,
        int written;

        mutex_lock(&wq->mutex);
-       written = scnprintf(buf, PAGE_SIZE, "%d\n", wq->attrs->nice);
+       if (wq->attrs->nice == RTPRI_NICE_LEVEL)
+               written = scnprintf(buf, PAGE_SIZE, "rt\n");
+       else
+               written = scnprintf(buf, PAGE_SIZE, "%d\n", wq->attrs->nice);

Can you also show rt in pr_cont_pool_info() and tools/workqueue/wq_dump.py?

Thanks.

Of course, I wasn't aware of that tool. Do you prefer in the same patch 
or separate?

Regards,

Tvrtko