On 6/8/21 3:35 PM, Greg KH wrote:
> On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
>> On 6/8/21 2:13 PM, Greg KH wrote:
>
>>> 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?
I mentioned C++ std::atomic and Boost.Atomic before. Those need variable
sized futexes.
The project you mention is probably Wine and its derivatives. Those need
variable sized futexes and "wait for multiple" operation. I'm not sure
about the "no plan to merge it back" part, I probably missed it in an
earlier discussion. There are multiple different patches and versions
out there, and I don't know which one it refers to. But WaitOnAddress
and WaitForMultipleObjects APIs are very important and I would assume
Wine wants to emulate those with best efficiency.
I have a media processing engine application that needs 64-bit futexes
would benefit from a "wait for multiple" function. Its source code is
not open currently, so I'm not sure if you can count it as a valid user.
There is a generic std::lock algorithm in C++ and an equivalent in
Boost.Thread that is supposed to lock multiple lockables (a mutex-like
object). Those could benefit from the "wait for multiple" function in
some cases, e.g. when the objects are actually futex-based mutexes, and
the function can access the internal futex. I'm not saying this will
definitely be implemented, it just looks like a possible optimization to me.
I think someone mentioned databases earlier in the discussion, but I
don't know the details. I hope someone will be able to expand.
On Tue, Jun 08, 2021 at 04:18:42PM +0300, Andrey Semashev wrote:
> On 6/8/21 3:35 PM, Greg KH wrote:
> > On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
> > > On 6/8/21 2:13 PM, Greg KH wrote:
> >
> > > > 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?
>
> I mentioned C++ std::atomic and Boost.Atomic before. Those need variable
> sized futexes.
And has anyone converted them to use this new api to see if it works
well or not?
As was pointed out to me numerous times when I tried to propose
readfile(), you need a real user that can show and prove it is needed
before we can take new syscalls, especially complex beasts like this
one.
thanks,
greg k-h
On 6/8/21 4:27 PM, Greg KH wrote:
> On Tue, Jun 08, 2021 at 04:18:42PM +0300, Andrey Semashev wrote:
>> On 6/8/21 3:35 PM, Greg KH wrote:
>>> On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
>>>> On 6/8/21 2:13 PM, Greg KH wrote:
>>>
>>>>> 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?
>>
>> I mentioned C++ std::atomic and Boost.Atomic before. Those need variable
>> sized futexes.
>
> And has anyone converted them to use this new api to see if it works
> well or not?
>
> As was pointed out to me numerous times when I tried to propose
> readfile(), you need a real user that can show and prove it is needed
> before we can take new syscalls, especially complex beasts like this
> one.
André has mentioned that he tested the patch set with patched Wine and
glibc.
I didn't patch Boost.Atomic or std::atomic, but it doesn't look to be
problematic. The only difference it would make there is to enable
futex2-based implementation for multiple atomic sizes and set up flags
to indicate the futex size, instead of only enabling futex-based
implementation for 32-bit atomics.