Re: [PATCH] rseq: defer time slice extension yield for sys_futex_wakey

[Thomas Gleixner]

On Mon, Sep 07 2026 at 13:21, Alice Ryhl wrote:
> On Sat, Sep 05, 2026 at 10:01:59PM +0200, Thomas Gleixner wrote:
>> What is the actual problem you are trying to solve?
>
> Basically in Tokio we have a bunch of critical regions that look like
> this:
>
> 	mutex_lock();
> 	list_add_tail(&my_list, new_item);
> 	mutex_unlock();
>
> and this:
>
> 	mutex_lock();
> 	next_job = list_first_entry(&my_list);
> 	list_del(&next_job);
> 	mutex_unlock();
>
> except in Rust.
>
> People are reporting bugs to me saying that this particular list in
> Tokio is causing significant contention for real-world workloads in
> production. The context here is backend/web servers.
>
> Thus, I am looking at various solutions to improving contention here.

Have you looked at lockless lists or queues? The above use case looks
more like a queue than a list. I'm sure there is some Rust
implementation by now.

Thanks,

        tglx