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

[Tvrtko Ursulin]

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@xxxxxxxxxx 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