From: Andrey Semashev <andrey.semashev@gmail.com>
To: "Nicholas Piggin" <npiggin@gmail.com>,
"André Almeida" <andrealmeid@collabora.com>
Cc: acme@kernel.org,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
corbet@lwn.net, Davidlohr Bueso <dave@stgolabs.net>,
Darren Hart <dvhart@infradead.org>,
fweimer@redhat.com, joel@joelfernandes.org, kernel@collabora.com,
krisman@collabora.com, libc-alpha@sourceware.org,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, malteskarupke@fastmail.fm,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
pgriffais@valvesoftware.com, Peter Oskolkov <posk@posk.io>,
Steven Rostedt <rostedt@goodmis.org>,
shuah@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
z.figura12@gmail.com
Subject: Re: [PATCH v4 00/15] Add futex2 syscalls
Date: Sat, 5 Jun 2021 11:56:13 +0300 [thread overview]
Message-ID: <6d8e3bb4-0cef-b991-9a16-1f03d10f131d@gmail.com> (raw)
In-Reply-To: <1622853816.mokf23xgnt.astroid@bobo.none>
On 6/5/21 4:09 AM, Nicholas Piggin wrote:
> Excerpts from André Almeida's message of June 5, 2021 6:01 am:
>> Às 08:36 de 04/06/21, Nicholas Piggin escreveu:
>
>>> I'll be burned at the stake for suggesting it but it would be great if
>>> we could use file descriptors. At least for the shared futex, maybe
>>> private could use a per-process futex allocator. It solves all of the
>>> above, although I'm sure has many of its own problem. It may not play
>>> so nicely with the pthread mutex API because of the whole static
>>> initialiser problem, but the first futex proposal did use fds. But it's
>>> an example of an alternate API.
>>>
>>
>> FDs and futex doesn't play well, because for futex_wait() you need to
>> tell the kernel the expected value in the futex address to avoid
>> sleeping in a free lock. FD operations (poll, select) don't have this
>> `value` argument, so they could sleep forever, but I'm not sure if you
>> had taken this in consideration.
>
> I had. The futex wait API would take a fd additional. The only
> difference is the waitqueue that is used when a sleep or wake is
> required is derived from the fd, not from an address.
>
> I think the bigger sticking points would be if it's too heavyweight an
> object to use (which could be somewhat mitigated with a simpler ida
> allocator although that's difficult to do with shared), and whether libc
> could sanely use them due to the static initialiser problem of pthread
> mutexes.
The static initialization feature is not the only benefit of the current
futex design, and probably not the most important one. You can work
around the static initialization in userspace, e.g. by initializing fd
to an invalid value and creating a valid fd upon the first use. Although
that would still incur a performance penalty and add a new source of
failure.
What is more important is that waiting on fd always requires a kernel
call. This will be terrible for performance of uncontended locks, which
is the majority of time.
Another important point is that a futex that is not being waited on
consumes zero kernel resources while fd is a limited resource even when
not used. You can have millions futexes in userspace and you are
guaranteed not to exhaust any limit as long as you have memory. That is
an important feature, and the current userspace is relying on it by
assuming that creating mutexes and condition variables is cheap.
Having futex fd would be useful in some cases to be able to integrate
futexes with IO. I did have use cases where I would have liked to have
FUTEX_FD in the past. These cases arise when you already have a thread
that operates on fds and you want to avoid having a separate thread that
blocks on futexes in a similar fashion. But, IMO, that should be an
optional opt-in feature. By far, not every futex needs to have an fd.
For just waiting on multiple futexes, the native support that futex2
provides is superior.
PS: I'm not asking FUTEX_FD to be implemented as part of futex2 API.
futex2 would be great even without it.
next prev parent reply other threads:[~2021-06-05 8:57 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 19:59 [PATCH v4 00/15] Add futex2 syscalls André Almeida
2021-06-03 19:59 ` [PATCH v4 01/15] futex2: Implement wait and wake functions André Almeida
2021-06-03 20:35 ` kernel test robot
2021-06-03 22:57 ` kernel test robot
2021-06-04 7:45 ` kernel test robot
2021-06-03 19:59 ` [PATCH v4 02/15] futex2: Add support for shared futexes André Almeida
2021-06-03 19:59 ` [PATCH v4 03/15] futex2: Implement vectorized wait André Almeida
2021-06-03 20:57 ` kernel test robot
2021-06-04 0:58 ` kernel test robot
2021-06-03 19:59 ` [PATCH v4 04/15] futex2: Implement requeue operation André Almeida
2021-06-03 21:07 ` kernel test robot
2021-06-03 19:59 ` [PATCH v4 05/15] futex2: Implement support for different futex sizes André Almeida
2021-06-04 0:23 ` kernel test robot
2021-06-04 0:23 ` kernel test robot
2021-06-06 19:12 ` Davidlohr Bueso
2021-06-06 23:01 ` Andrey Semashev
2021-06-03 19:59 ` [PATCH v4 06/15] futex2: Add compatibility entry point for x86_x32 ABI André Almeida
2021-06-03 19:59 ` [PATCH v4 07/15] docs: locking: futex2: Add documentation André Almeida
2021-06-06 19:23 ` Davidlohr Bueso
2021-06-03 19:59 ` [PATCH v4 08/15] selftests: futex2: Add wake/wait test André Almeida
2021-06-03 19:59 ` [PATCH v4 09/15] selftests: futex2: Add timeout test André Almeida
2021-06-03 19:59 ` [PATCH v4 10/15] selftests: futex2: Add wouldblock test André Almeida
2021-06-03 19:59 ` [PATCH v4 11/15] selftests: futex2: Add waitv test André Almeida
2021-06-03 19:59 ` [PATCH v4 12/15] selftests: futex2: Add requeue test André Almeida
2021-06-03 19:59 ` [PATCH v4 13/15] selftests: futex2: Add futex sizes test André Almeida
2021-06-03 19:59 ` [PATCH v4 14/15] perf bench: Add futex2 benchmark tests André Almeida
2021-06-03 19:59 ` [PATCH v4 15/15] kernel: Enable waitpid() for futex2 André Almeida
2021-06-04 4:51 ` [PATCH v4 00/15] Add futex2 syscalls Zebediah Figura
2021-06-04 17:04 ` André Almeida
2021-06-04 11:36 ` Nicholas Piggin
2021-06-04 20:01 ` André Almeida
2021-06-05 1:09 ` Nicholas Piggin
2021-06-05 8:56 ` Andrey Semashev [this message]
2021-06-06 11:57 ` Nicholas Piggin
2021-06-06 13:15 ` Andrey Semashev
2021-06-08 1:25 ` Nicholas Piggin
2021-06-08 11:03 ` Andrey Semashev
2021-06-08 11:13 ` Greg KH
2021-06-08 11:44 ` Peter Zijlstra
2021-06-08 14:31 ` Davidlohr Bueso
2021-06-08 12:06 ` Andrey Semashev
2021-06-08 12:33 ` Greg KH
2021-06-08 12:35 ` Greg KH
2021-06-08 13:18 ` Andrey Semashev
2021-06-08 13:27 ` Greg KH
2021-06-08 13:41 ` Andrey Semashev
2021-06-08 17:06 ` Zebediah Figura
2021-06-08 14:14 ` André Almeida
2021-06-07 15:40 ` André Almeida
2021-06-08 1:31 ` Nicholas Piggin
2021-06-08 2:33 ` Davidlohr Bueso
2021-06-08 4:45 ` Nicholas Piggin
2021-06-08 12:26 ` Sebastian Andrzej Siewior
2021-06-08 14:23 ` Peter Zijlstra
2021-06-08 14:57 ` Sebastian Andrzej Siewior
2021-06-08 15:04 ` André Almeida
2021-06-08 18:08 ` Adhemerval Zanella
2021-06-08 18:19 ` Florian Weimer
2021-06-08 18:22 ` Adhemerval Zanella
2021-06-09 16:26 ` 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=6d8e3bb4-0cef-b991-9a16-1f03d10f131d@gmail.com \
--to=andrey.semashev@gmail.com \
--cc=acme@kernel.org \
--cc=andrealmeid@collabora.com \
--cc=bigeasy@linutronix.de \
--cc=corbet@lwn.net \
--cc=dave@stgolabs.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=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=pgriffais@valvesoftware.com \
--cc=posk@posk.io \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.