LKML Archive on lore.kernel.org
 help / color / Atom feed
From: "André Almeida" <andrealmeid@collabora.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	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,
	Peter Oskolkov <posk@posk.io>
Subject: Re: [PATCH v3 00/13] Add futex2 syscalls
Date: Thu, 6 May 2021 11:48:36 -0300
Message-ID: <36e6951e-e7a9-5e82-200e-17668f02447f@collabora.com> (raw)
In-Reply-To: <87bl9pi7if.ffs@nanos.tec.linutronix.de>

Hi Thomas, Peter,

Às 11:23 de 05/05/21, Thomas Gleixner escreveu:
> On Wed, May 05 2021 at 14:31, Peter Zijlstra wrote:
> 
>> On Tue, Apr 27, 2021 at 08:12:35PM -0300, André Almeida wrote:
>>> Hi,
>>>
>>> This patch series introduces the futex2 syscalls.
>>
>> I still utterly detest that this adds a second hash-table for no
>> descernable reason.
>>
>> The new syscall interface does not depend on that in any way, you
>> previously implemented the multi-wait thing in the current futex code.
>>
>> Like I said last time; I'm okay with the new interface, but I don't see
>> why you need to reimplement the insides, that's all pointless code
>> duplication.
> 
> The real question is whether we really need to model all of this along
> the existing futex functionality. I wouldn't mind a new infrastructure
> which addresses all the other known issues of futexes and makes the
> overall design less horrible than what we have now.
> 

Thank you for the feedback. I think we are completing another full 
circle on the proposals. I've proposed a futex2 interface that would use 
the current futex infrastructure[0], but my understanding is that this 
is discouraged given it needs to do big changes in the current futex 
code. Given that, I proceeded with developing a new code for futex2, 
taking in consideration those new use cases (waitv, NUMA, sizes) and 
known issues.

As you know, my original goal with this work is to have a native and 
efficient way to wait on multiple objects. Right now, we've proposed it 
in three different ways, but so far none had much success in being 
merged. Of course, I want to take the approach that better fits the 
community goals, as this patchset suggests - a work that goes away 
further than just implementing a multi-wait feature. But for the benefit 
of not walking in circles, what we need back is a clear direction, in 
order to proceed that.

> But that needs input from futex users (libraries and other horrible
> wrappers) to figure out what they really need, hate, like or do not care
> about.
> 

I think it's clear the use case for "wait on multiple" as a way to 
emulate WinAPI and for Linux native loads like game engines is valid. 
We have been running it in the field with success for the past year or 
so. I'm also working with userspace communities to get a better sense of 
how this and other features would work in the real world. You can read 
an example of that effort with Chromium developers at [1], and there are 
more to come.

Maybe support for multiple futexes and futex2 are disjoint things? The 
multi-wait can be achieved through a (somewhat) simple implementation, 
on the old interface or in a new one, while for futex2 we are still 
unsure about how it should look like and its blocking this feature.

> Without that we are bound to pile more crap on the existing pile of
> horrors forever.
> 
> Thanks,
> 
>          tglx
> 

Thanks,
	André

[0] 
https://lore.kernel.org/lkml/20200612185122.327860-2-andrealmeid@collabora.com/
[1] https://groups.google.com/a/chromium.org/g/chromium-dev/c/5hpH3ckr6_Y

      reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27 23:12 André Almeida
2021-04-27 23:12 ` [PATCH v3 01/13] futex2: Implement wait and wake functions André Almeida
2021-04-27 23:12 ` [PATCH v3 02/13] futex2: Add support for shared futexes André Almeida
2021-04-27 23:12 ` [PATCH v3 03/13] futex2: Implement vectorized wait André Almeida
2021-04-27 23:12 ` [PATCH v3 04/13] futex2: Implement requeue operation André Almeida
2021-04-27 23:12 ` [PATCH v3 05/13] futex2: Add compatibility entry point for x86_x32 ABI André Almeida
2021-04-27 23:12 ` [PATCH v3 06/13] docs: locking: futex2: Add documentation André Almeida
2021-04-27 23:12 ` [PATCH v3 07/13] selftests: futex2: Add wake/wait test André Almeida
2021-04-27 23:12 ` [PATCH v3 08/13] selftests: futex2: Add timeout test André Almeida
2021-04-27 23:12 ` [PATCH v3 09/13] selftests: futex2: Add wouldblock test André Almeida
2021-04-27 23:12 ` [PATCH v3 10/13] selftests: futex2: Add waitv test André Almeida
2021-04-27 23:12 ` [PATCH v3 11/13] selftests: futex2: Add requeue test André Almeida
2021-04-27 23:12 ` [PATCH v3 12/13] perf bench: Add futex2 benchmark tests André Almeida
2021-04-27 23:12 ` [PATCH v3 13/13] kernel: Enable waitpid() for futex2 André Almeida
2021-05-05 12:31 ` [PATCH v3 00/13] Add futex2 syscalls Peter Zijlstra
2021-05-05 14:23   ` Thomas Gleixner
2021-05-06 14:48     ` André Almeida [this message]

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=36e6951e-e7a9-5e82-200e-17668f02447f@collabora.com \
    --to=andrealmeid@collabora.com \
    --cc=acme@kernel.org \
    --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=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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git
	git clone --mirror https://lore.kernel.org/lkml/10 lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git