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 [email protected] 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

Reply via email to