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_NICEThese 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
