linux-kernel - Re: [linus:master] [futex] 7c4f75a21f: will-it-scale.per_thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250603155152.WGVMzZhN@linutronix.de>
Date: Tue, 3 Jun 2025 17:51:52 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: kernel test robot <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [linus:master] [futex]  7c4f75a21f: will-it-scale.per_thread_ops
 98.3% regression

On 2025-05-29 12:50:44 [+0800], kernel test robot wrote:
> 
> 
> Hello,
Hi,

> kernel test robot noticed a 98.3% regression of will-it-scale.per_thread_ops on:
> commit: 7c4f75a21f636486d2969d9b6680403ea8483539 ("futex: Allow automatic allocation of process wide futex hash")

there are several reports about a regressions and improvements regarding
the futex per-process series. The regression reports outweigh
improvements. The percentages vary also the offending commit does.

The test uses "random" memory allocations and locking so we get what we
get. We could use the prctl() function to set it back to the global hash
and let it behave as it did before.

I'm not exactly sure what causes this. It could be "less" hash buckets
and therefore higher hash collision or the atomic-inc/ dec on the hash
bucket. The commit referenced in the report creates only a private hash
of 16 buckets. A few commits later this is change to auto-scale. So it
would get better if the smaller hash is the problem.

Sebastian