From: Peter Zijlstra <peterz@infradead.org>
To: tglx@linutronix.de, axboe@kernel.dk
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
mingo@redhat.com, dvhart@infradead.org, dave@stgolabs.net,
andrealmeid@igalia.com, Andrew Morton <akpm@linux-foundation.org>,
urezki@gmail.com, hch@infradead.org, lstoakes@gmail.com,
Arnd Bergmann <arnd@arndb.de>,
linux-api@vger.kernel.org, linux-mm@kvack.org,
linux-arch@vger.kernel.org, malteskarupke@web.de,
steve.shaw@intel.com, marko.makela@mariadb.com,
andrei.artemev@intel.com
Subject: futex2 numa stuff
Date: Fri, 22 Sep 2023 22:01:20 +0200 [thread overview]
Message-ID: <20230922200120.011184118@infradead.org> (raw)
In-Reply-To: <20230921104505.717750284@noisy.programming.kicks-ass.net>
Hi!
Updated version of patch 15/15 and a few extra patches for testing the
FUTEX2_NUMA bits. The last patch (17/15) should never be applied for anything
you care about and exists purely because I'm too lazy to generate actual
hash-bucket contention.
On my 2 node IVB-EP:
$ echo FUTEX_SQUASH > /debug/sched/features
Effectively reducing each node to 1 bucket.
$ numactl -m0 -N0 ./futex_numa -c10 -t2 -n0 -N0 &
numactl -m1 -N1 ./futex_numa -c10 -t2 -n0 -N0
...
contenders: 16154935
contenders: 16202472
$ numactl -m0 -N0 ./futex_numa -c10 -t2 -n0 -N0 &
numactl -m1 -N1 ./futex_numa -c10 -t2 -n0 -N1
contenders: 48584991
contenders: 48680560
(loop counts, higher is better)
Clearly showing how separating the hashes works.
The first one runs 10 contenders on each node but forces the (numa) futex to
hash to node 0 for both. This ensures all 20 contenders hash to the same
bucket and *ouch*.
The second one does the same, except now fully separates the nodes. Performance
is much improved.
Proving the per-node hashing actually works as advertised.
Further:
$ ./futex_numa -t2 -n50000 -s1 -N
...
node: -1
node: -1
node: 0
node: 0
node: -1
node: -1
node: 1
node: 1
...
total: 8980
Shows how a FUTEX2_NUMA lock can bounce around the nodes. The test has some
trivial asserts trying to show critical section integrity, but otherwise does
lock+unlock cycles with a nanosleep.
This both illustrates how to build a (trivial) lock using FUTEX2_NUMA and
proves the functionality works.
next prev parent reply other threads:[~2023-09-22 20:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-21 10:45 [PATCH v3 00/15] futex: More futex2 bits peterz
2023-09-21 10:45 ` [PATCH v3 04/15] futex: Validate futex value against futex size peterz
2023-09-21 10:45 ` [PATCH v3 05/15] futex: Add sys_futex_wake() peterz
2023-09-21 10:45 ` [PATCH v3 07/15] futex: Add sys_futex_wait() peterz
2023-09-21 10:45 ` [PATCH v3 08/15] futex: Propagate flags into get_futex_key() peterz
2023-09-21 10:45 ` [PATCH v3 09/15] futex: Add flags2 argument to futex_requeue() peterz
2023-09-21 10:45 ` [PATCH v3 10/15] futex: Add sys_futex_requeue() peterz
2023-09-22 9:35 ` Ingo Molnar
2023-09-22 11:03 ` Peter Zijlstra
2023-09-22 13:56 ` Jens Axboe
2023-09-21 10:45 ` [PATCH v3 11/15] mm: Add vmalloc_huge_node() peterz
2023-09-21 10:45 ` [PATCH v3 12/15] futex: Implement FUTEX2_NUMA peterz
2023-09-21 10:45 ` [PATCH v3 13/15] futex: Propagate flags into futex_get_value_locked() peterz
2023-09-21 10:45 ` [PATCH v3 14/15] futex: Enable FUTEX2_{8,16} peterz
2023-09-21 10:45 ` [PATCH v3 15/15] futex,selftests: Extend the futex selftests peterz
2023-09-21 11:41 ` Peter Zijlstra
[not found] ` <20230921105248.048643656@noisy.programming.kicks-ass.net>
2023-09-21 15:14 ` [PATCH v3 06/15] futex: FLAGS_STRICT Thomas Gleixner
2023-09-22 20:01 ` Peter Zijlstra [this message]
2023-09-22 20:01 ` [PATCH 15/15] futex,selftests: Extend the futex selftests Peter Zijlstra
2023-09-22 20:01 ` [PATCH 16/15] futex,selftests: Extend the futex selftests for NUMA Peter Zijlstra
2023-09-22 20:01 ` [PATCH 17/15] [HACK] futex: Force futex hash collision Peter Zijlstra
2023-09-28 13:40 ` futex2 numa stuff Davidlohr Bueso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230922200120.011184118@infradead.org \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=andrealmeid@igalia.com \
--cc=andrei.artemev@intel.com \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=hch@infradead.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=malteskarupke@web.de \
--cc=marko.makela@mariadb.com \
--cc=mingo@redhat.com \
--cc=steve.shaw@intel.com \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).