Re: [PATCH] futex: Avoid hash-bucket locking for mismatched waits

[Usama Arif <usama.arif@linux.dev>]

On Thu, 20 Aug 2026 19:05:31 +0100 Usama Arif <usama.arif@linux.dev> wrote:

> 
> 
> On 20/08/2026 17:23, Thomas Gleixner wrote:
> > Usama!
> > 
> > On Thu, Aug 20 2026 at 16:19, Usama Arif wrote:
> >> On 14/08/2026 17:02, Thomas Gleixner wrote:
> >>> --- a/kernel/futex/waitwake.c
> >>> +++ b/kernel/futex/waitwake.c
> >>> @@ -857,7 +857,21 @@ int futex_wait_setup(u32 __user *uaddr,
> >>>  		CLASS(hbr, hbr)(&q->key);
> >>>  		auto hb = hbr.hb;
> >>>  
> >>> -		futex_q_lock(q, hb);
> >>> +		futex_hb_waiters_inc(hb);
> >>> +		q->lock_ptr = &hb->lock;
> >>> +
> >>> +		if (!spin_trylock(&hb->lock)) {
> >>> +			ret = get_user_inline(uval, uaddr);
> >>> +			if (ret) {
> >>> +				futex_hb_waiters_dec(hb);
> >>> +				return ret;
> >>> +			}
> >>> +			if (uval != val) {
> >>> +				futex_hb_waiters_dec(hb);
> >>> +				return -EWOULDBLOCK;
> >>> +			}
> >>> +			spin_lock(&hb->lock);
> >>> +		}
> >>>  
> >>>  		ret = futex_get_value_locked(&uval, uaddr);
> >>>
> >> I like this approach; it makes the trade-off much better than my patch.
> >> When spin_trylock() succeeds, the matching path performs only the existing 
> >> single user access, rather than the two accesses in my version.
> > 
> > Correct.
> > 
> >> Is it alright if I send v2 of the patch with your diff above? Or would you
> >> like to send it?
> > 
> > Go wild.
> > 
> 
> Thanks! I am going to try and run this in production workloads to gather data.
> Should be done in the next few days and send it early next week.

Just coming back on this, its taking more time than I would like to setup a
hosts with custom kernel on production traffic, I will update here once I have
something with this patch.