Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v3 1/4] futex: Implement mechanism to wait on any of
 several futexes
To:     Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        =?UTF-8?Q?Andr=c3=a9_Almeida?= <andrealmeid@collabora.com>
CC:     <linux-kernel@vger.kernel.org>, <kernel@collabora.com>,
        <krisman@collabora.com>, <shuah@kernel.org>,
        <linux-kselftest@vger.kernel.org>, <rostedt@goodmis.org>,
        <ryao@gentoo.org>, <dvhart@infradead.org>, <mingo@redhat.com>,
        <z.figura12@gmail.com>, <steven@valvesoftware.com>,
        <steven@liquorix.net>, <malteskarupke@web.de>
References: <20200213214525.183689-1-andrealmeid@collabora.com>
 <20200213214525.183689-2-andrealmeid@collabora.com>
 <20200228190717.GM18400@hirez.programming.kicks-ass.net>
 <20200228194958.GO14946@hirez.programming.kicks-ass.net>
 <87tv3aflqm.fsf@nanos.tec.linutronix.de>
From:   "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Message-ID: <967d5047-2cb6-d6d8-6107-edb99a4c9696@valvesoftware.com>
Date:   Fri, 28 Feb 2020 16:29:05 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <87tv3aflqm.fsf@nanos.tec.linutronix.de>
Content-Language: en-US
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 2/28/20 1:25 PM, Thomas Gleixner wrote:
> Peter Zijlstra <peterz@infradead.org> writes:
>> On Fri, Feb 28, 2020 at 08:07:17PM +0100, Peter Zijlstra wrote:
>>> So I have a problem with this vector layout, it doesn't allow for
>>> per-futex flags, and esp. with that multi-size futex support that
>>> becomes important, but also with the already extand private/shared and
>>> wait_bitset flags this means you cannot have a vector with mixed wait
>>> types.
>>
>> Alternatively, we throw the entire single-syscall futex interface under
>> the bus and design a bunch of new syscalls that are natively vectored or
>> something.
>>
>> Thomas mentioned something like that, the problem is, ofcourse, that we
>> then want to fix a whole bunch of historical ills, and the probmem
>> becomes much bigger.
>=20
> We keep piling features on top of an interface and mechanism which is
> fragile as hell and horrible to maintain. Adding vectoring, multi size
> and whatever is not making it any better.
>=20
> There is also the long standing issue with NUMA, which we can't address
> with the current pile at all.
>=20
> So I'm really advocating that all involved parties sit down ASAP and
> hash out a new and less convoluted mechanism where all the magic new
> features can be addressed in a sane way so that the 'F' in Futex really
> only means Fast and not some other word starting with 'F'.

Are you specifically talking about the interface, or the mechanism=20
itself? Would you be OK with a new syscall that calls into the same code=20
as this patch? It does seem like that's what we want, so if we rewrote a=20
mechanism I'm not convinced it would come out any different. But, the=20
interface itself seems fair-game to rewrite, as the current futex=20
syscall is turning into an ioctl of sorts.

This solves a real problem with a real usecase; so I'd like to stay=20
practical and not go into deeper issues like solving NUMA support for=20
all of futex in the interest of users waiting at the other end. Can you=20
point us to your preferred approach just for the scope of what we're=20
trying to accomplish?

>=20
> Thanks,
>=20
>          tglx
>=20