Re: [PATCH v7 3/4] workqueue: Add support for real-time workers

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

Hi Tejun,

On 23/10/2026 22:28, Tejun Heo wrote:
> Hello, Tvrtko.
> 
> On Thu, Oct 22, 2026 at 10:38:47AM +0100, Tvrtko Ursulin wrote:
>>   struct workqueue_attrs {
>>   	/**
>> -	 * @nice: nice level
>> +	 * @prio: priority encoded analogous to task_struct->prio.
>>   	 */
>> -	int nice;
>> +	int prio;
> 
> Can the nice to prio conversion be split into a preparation patch with
> no functional change, so that this patch only adds WQ_RT on top?

Can do. I'll get to it the week after next. (Tweaks to other patches in 
the series as well.) Should I switch to a different base branch by then?

>>   sanitize_immutable_workqueue_attrs(struct workqueue_struct *wq,
>>   				   struct workqueue_attrs *attrs)
>>   {
>> +	if (wq->flags & WQ_RT) {
>> +		attrs->prio = RT_PRIORITY;
>> +		/* Strict CPU affinity for low latency execution. */
>> +		attrs->affn_scope = WQ_AFFN_CPU;
>> +		attrs->affn_strict = true;
>> +	}
> 
> Can WQ_RT set only the priority and leave the affinity at the defaults?
> If the pinning is needed for the latency, can you share numbers with
> and without it?

I could do that although note the current numbers are actually without 
strict affinity because that is what the initial RFC did. Then in msg-id 
  b3e5bcb21184d13c7c631daac955f465@kernel.org you suggested to make them 
strict affinity. So latencies 95% and 9% percentiles were already good 
enough without it. But if you are curious how much better strict 
affinity makes them I can measure, it is not a huge effort.

>>   	mutex_lock(&wq->mutex);
>> -	written = scnprintf(buf, PAGE_SIZE, "%d\n", wq->attrs->nice);
>> +	if (wq->attrs->prio == RT_PRIORITY)
>> +		written = scnprintf(buf, PAGE_SIZE, "rt\n");
>> +	else
>> +		written = scnprintf(buf, PAGE_SIZE, "%d\n",
>> +				    PRIO_TO_NICE(wq->attrs->prio));
> 
> Can the sysfs interface comment above struct wq_device be updated too?
> It still lists nice as RW int, while nice reads "rt" and is read-only
> for WQ_RT.

Sure, I did not spot that comment until now. Tunnel vision it seems. :)

>> +rt_prio = prog.constant('RT_PRIORITY', filename='kernel/workqueue.c')
>> ...
>> +    nice = pool.attrs.prio.value_()
>> +    if nice == rt_prio:
>> +        nice = 'rt'
>> +    else:
>> +        nice = nice - 120 # PRIO_TO_NICE
> 
> These fail on a kernel without this patch, where neither RT_PRIORITY
> nor attrs.prio exists. Can they fall back to nice, the way wq_attrs()
> falls back to unbound_attrs for the earlier rename?

Hmm.. I could do that, but since the tool ships within the kernel does 
it _need_ to have backward compatibility regarding kernel _internal_ 
implementation details?

Regards,

Tvrtko