From: "Theodore Ts'o" <tytso@mit.edu>
To: "André Almeida" <andrealmeid@collabora.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Darren Hart <dvhart@infradead.org>,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
kernel@collabora.com, krisman@collabora.com,
pgriffais@valvesoftware.com, z.figura12@gmail.com,
joel@joelfernandes.org, malteskarupke@fastmail.fm,
linux-api@vger.kernel.org, fweimer@redhat.com,
libc-alpha@sourceware.org, linux-kselftest@vger.kernel.org,
shuah@kernel.org, acme@kernel.org, corbet@lwn.net
Subject: Re: [RFC PATCH v2 00/13] Add futex2 syscall
Date: Thu, 4 Mar 2021 10:01:14 -0500 [thread overview]
Message-ID: <YED2OrBdsiYWMqpp@mit.edu> (raw)
In-Reply-To: <20210304004219.134051-1-andrealmeid@collabora.com>
On Wed, Mar 03, 2021 at 09:42:06PM -0300, André Almeida wrote:
> ** Performance
>
> - For comparing futex() and futex2() performance, I used the artificial
> benchmarks implemented at perf (wake, wake-parallel, hash and
> requeue). The setup was 200 runs for each test and using 8, 80, 800,
> 8000 for the number of threads, Note that for this test, I'm not using
> patch 14 ("kernel: Enable waitpid() for futex2") , for reasons explained
> at "The patchset" section.
How heavily contended where the benchmarks? One of the benefits of
the original futex was that no system call was necessary in the happy
path when the lock is uncontended. Especially on a non-NUMA system
(which are the far more common case), since that's where relying on a
single memory access was a huge win for the original futex. I would
expect that futex2 will fare worse in this particular case, since it
requires a system call entry for all operations --- the question is
how large is the delta in this worst case (for futex2) and best case
(for futex) scenario.
Cheers,
- Ted
next prev parent reply other threads:[~2021-03-04 15:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-04 0:42 [RFC PATCH v2 00/13] Add futex2 syscall André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 01/13] futex2: Implement wait and wake functions André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 02/13] futex2: Add support for shared futexes André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 03/13] futex2: Implement vectorized wait André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 04/13] futex2: Implement requeue operation André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 05/13] futex2: Add compatibility entry point for x86_x32 ABI André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 06/13] docs: locking: futex2: Add documentation André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 07/13] selftests: futex2: Add wake/wait test André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 08/13] selftests: futex2: Add timeout test André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 09/13] selftests: futex2: Add wouldblock test André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 10/13] selftests: futex2: Add waitv test André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 11/13] selftests: futex2: Add requeue test André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 12/13] perf bench: Add futex2 benchmark tests André Almeida
2021-03-04 0:42 ` [RFC PATCH v2 13/13] kernel: Enable waitpid() for futex2 André Almeida
2021-03-04 5:44 ` [RFC PATCH v2 00/13] Add futex2 syscall Peter Oskolkov
2021-03-04 18:58 ` André Almeida
2021-03-05 20:03 ` Peter Oskolkov
2021-03-05 20:08 ` Peter Oskolkov
2021-03-04 15:01 ` Theodore Ts'o [this message]
2021-03-04 19:15 ` André Almeida
2021-03-07 11:34 ` Stefan Metzmacher
2021-03-07 11:56 ` Daurnimator
2021-03-08 11:52 ` Stefan Metzmacher
2021-03-08 11:11 ` David Laight
2021-03-08 11:55 ` Stefan Metzmacher
2021-03-08 16:18 ` Zebediah Figura
2021-03-08 17:33 ` David Laight
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=YED2OrBdsiYWMqpp@mit.edu \
--to=tytso@mit.edu \
--cc=acme@kernel.org \
--cc=andrealmeid@collabora.com \
--cc=bigeasy@linutronix.de \
--cc=corbet@lwn.net \
--cc=dvhart@infradead.org \
--cc=fweimer@redhat.com \
--cc=joel@joelfernandes.org \
--cc=kernel@collabora.com \
--cc=krisman@collabora.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=malteskarupke@fastmail.fm \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pgriffais@valvesoftware.com \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=z.figura12@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).