linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Andrey Semashev <andrey.semashev@gmail.com>
Cc: "Nicholas Piggin" <npiggin@gmail.com>,
	"André Almeida" <andrealmeid@collabora.com>,
	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: Tue, 8 Jun 2021 14:35:14 +0200	[thread overview]
Message-ID: <YL9kApyE6FbG/hru@kroah.com> (raw)
In-Reply-To: <8fa8b7fd-58ae-9467-138d-4ff4f32f68f7@gmail.com>

On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
> On 6/8/21 2:13 PM, Greg KH wrote:
> > On Tue, Jun 08, 2021 at 02:03:50PM +0300, Andrey Semashev wrote:
> > > On 6/8/21 4:25 AM, Nicholas Piggin wrote:
> > > > 
> > > > Are shared pthread mutexes using existing pthread APIs that are today
> > > > implemented okay with futex1 system call a good reason to constrain
> > > > futex2 I wonder? Or do we have an opportunity to make a bigger change
> > > > to the API so it suffers less from non deterministic latency (for
> > > > example)?
> > > 
> > > If futex2 is not able to cover futex1 use cases then it cannot be viewed as
> > > a replacement. In the long term this means futex1 cannot be deprecated and
> > > has to be maintained. My impression was that futex1 was basically
> > > unmaintainable(*) and futex2 was an evolution of futex1 so that users of
> > > futex1 could migrate relatively easily and futex1 eventually removed. Maybe
> > > my impression was wrong, but I would like to see futex2 as a replacement and
> > > extension of futex1, so the latter can be deprecated at some point.
> > 
> > You can never delete a kernel system call, so even if you "deprecate"
> > it, it still needs to be supported for forever.
> 
> If I'm not mistaken, some syscalls were dropped from kernel in the past,
> after it was established they are no longer used. So it is not impossible,
> though might be more difficult specifically with futex.
> 
> > Best of all would be if internally your "futex2" code would replace the
> > "futex1" code so that there is no two different code bases.  That would
> > be the only sane way forward, having 2 code bases to work with is just
> > insane.
> 
> Yes, implementing futex1 in terms of futex2 internally is a possible way
> forward. Though I'm not sure it is reasonable to require that to be done in
> the initial futex2 submission. This requires all of the futex1 functionality
> to implemented in futex2 from the start, which I think is too much to ask.
> Even with some futex1 features missing, futex2 would be already very much
> useful to users, and it is easier to implement the missing bits
> incrementally over time.

Then do it the other way around, as Peter points out.

> > So what's keeping the futex2 code from doing all that futex1 does so
> > that the futex1 code can be deleted internally?
> 
> I think, André will answer this, but my guess is, as stated above, this is a
> lot of work and time while the intermediate version is already useful.

useful to who?  I still do not understand what users will be needing
this.  All I can tell is a single userspace program wants to use it, and
that is a fork from the real project it was based on and that the
maintainers have no plan to merge it back.

So who does need/want this?

thanks,

greg k-h

  parent reply	other threads:[~2021-06-08 12:35 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 19:59 André Almeida
2021-06-03 19:59 ` [PATCH v4 01/15] futex2: Implement wait and wake functions André Almeida
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 19:59 ` [PATCH v4 04/15] futex2: Implement requeue operation André Almeida
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-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
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 [this message]
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=YL9kApyE6FbG/hru@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=acme@kernel.org \
    --cc=andrealmeid@collabora.com \
    --cc=andrey.semashev@gmail.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 \
    --subject='Re: [PATCH v4 00/15] Add futex2 syscalls' \
    /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

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).