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

[Tvrtko Ursulin <tvrtko.ursulin@igalia.com>]

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