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

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

On 16/08/2026 20:10, Tejun Heo wrote:
> (cc'ing Breno as he has been working in the area)
> 
> Hello,
> 
> Sorry about the delay.

Same here so no worries, summer holidays.. :)

> On Tue, Aug 04, 2026 at 11:19:24AM +0100, Tvrtko Ursulin wrote:
>>   struct workqueue_attrs {
>>   	/**
>> -	 * @nice: nice level
>> +	 * @prio: priority level
>> +	 */
>> +	enum wq_priority prio;
>> +
>> +	/**
>> +	 * @nice: nice level for WQ_PRIO_HIGH
>>   	 */
>>   	int nice;
> 
> I find this rather confusing. We're scattering the same internal state
> across multiple fields. If you look at scheduler code, rt and normal nice
> values are encoded into a single prio value, maybe we can do the same?

I thought it was more elegant to split the policy from the priority 
within a policy for call sites which only look up the policy. I can 
change it to encode all in a single integer or something. Alternative 
will be to call some helpers here and there which answers the "is this a 
rt policy" based on a range checks. At which point it felt one word in 
the struct is nicer than conditionals across the code. Your call what 
you prefer.

>>   static int alloc_and_link_pwqs(struct workqueue_struct *wq)
>>   {
>> -	bool highpri = wq->flags & WQ_HIGHPRI;
>> -	int cpu, ret;
>> +	int prio, cpu, ret;
>>   
>>   	lockdep_assert_held(&wq_pool_mutex);
>>   
>> +	if (wq->flags & WQ_RTPRI)
>> +		prio = WQ_PRIO_RT;
>> +	else if (wq->flags & WQ_HIGHPRI)
>> +		prio = WQ_PRIO_HIGH;
>> +	else
>> +		prio = WQ_PRIO_NORMAL;
>> +
>>   	wq->cpu_pwq = alloc_percpu(struct pool_workqueue *);
>>   	if (!wq->cpu_pwq)
>>   		goto enomem;
>> @@ -5622,7 +5637,7 @@ static int alloc_and_link_pwqs(struct workqueue_struct *wq)
>>   			struct pool_workqueue **pwq_p;
>>   			struct worker_pool *pool;
>>   
>> -			pool = &(per_cpu_ptr(pools, cpu)[highpri]);
>> +			pool = &(per_cpu_ptr(pools, cpu)[prio]);
> 
> And this looks a bit confusing too because there's no per-cpu counterpart
> but it looks like there should be.

I did not quite manage to follow you here. Was this not the per cpu 
part, with unbound and ordered down lower? You have to excuse me I am 
new in this code.

> I wonder whether this would look better after the percpu and unbound pool
> unification that Breno is working on.

I suppose this landed by now? I can see some changes so once we clarify 
the above opens I will rebase and adjust.

Regards,

Tvrtko