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

[Tvrtko Ursulin]

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