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

[Tvrtko Ursulin]

On 26/10/2026 18:37, Tejun Heo wrote:
> Hello, Tvrtko.
>
> On Sat, Oct 24, 2026 at 09:33:42AM +0100, Tvrtko Ursulin wrote:
> > 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?
>
> I just branched wq/for-7.5. That should work as the base.
>
> > But if you are curious how much better strict
> > affinity makes them I can measure, it is not a huge effort.
>
> Yes, numbers with and without strict affinity would be great.

Re-measured submit latencies on three relevant setups:

    us	   7.3.0   WQ_RT   +strict_affinity

   median    30      21          11
    min       2       3           2
    max     1038    941         108
   95pct    2384     49          28
   98pct    2922     63          51

I suppose we can interpret this in two ways. Plain WQ_RT is already a 
huge improvement, and although strict affinity is even better, the twice 
as good median probably isn't a huge selling point. So question is do 
tail latencies above the 98th percentile matter, or are they visible in 
the user experience. That I have no experience to answer.

FWIW I have locally split out the patch which adds strict affinity on 
top of WQ_RT so we can trivially go either way.

> > 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?
>
> It's just a nice-to-have, but other parts of the script already support
> older kernels, so falling back would be good if it doesn't add too much
> complexity.

Okay done.

Regards,

Tvrtko