linux-kernel - Potential Regression in futex Performance from v6.9 to v6.10-rc1 and v6.11-rc4

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-next>] [day] [month] [year] [list]

Message-ID: <CADYN=9JBw6kq4E9aA=Pr1rFy-6tY-j-XOthQVYVw6ptmj11=HA@mail.gmail.com>
Date: Tue, 3 Sep 2024 14:21:52 +0200
From: Anders Roxell <anders.roxell@...aro.org>
To: David Hildenbrand <david@...hat.com>
Cc: Arnd Bergmann <arnd@...db.de>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, 
	Peter Zijlstra <peterz@...radead.org>, dvhart@...radead.org, dave@...olabs.net, 
	andrealmeid@...lia.com, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>
Subject: Potential Regression in futex Performance from v6.9 to v6.10-rc1 and v6.11-rc4

Hi,

I've noticed that the futex01-thread-* tests in will-it-scale-sys-threads
are running about 2% slower on v6.10-rc1 compared to v6.9, and this
slowdown continues with v6.11-rc4. I am focused on identifying any
performance regressions greater than 2% that occur in automated
testing on arm64 HW.

Using git bisect, I traced the issue to commit
f002882ca369 ("mm: merge folio_is_secretmem() and
folio_fast_pin_allowed() into gup_fast_folio_allowed()").

My tests were performed on m7g.large and m7g.metal instances:

* The slowdown is consistent regardless of the number of threads;
   futex1-threads-128 performs similarly to futex1-threads-2, indicating
   there is no scalability issue, just a minor performance overhead.
* The test doesn’t involve actual futex operations, just dummy wake/wait
   on a variable that isn’t accessed by other threads, so the results might
   not be very significant.

Given that this seems to be a minor increase in code path length rather
than a scalability issue, would this be considered a genuine regression?

Cheers,
Anders