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

[Tvrtko Ursulin <tvrtko.ursulin@igalia.com>]

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