lkml.org 
[lkml]   [2021]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 00/13] Add futex2 syscalls
From
Date
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

\
 
 \ /
  Last update: 2021-05-06 16:49    [W:0.084 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site