[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87imji7or0.fsf@oldenburg2.str.redhat.com>
Date: Thu, 05 Mar 2020 17:25:23 +0100
From: Florian Weimer <fweimer@...hat.com>
To: André Almeida <andrealmeid@...labora.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
"Pierre-Loup A. Griffais" <pgriffais@...vesoftware.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org, kernel@...labora.com,
krisman@...labora.com, shuah@...nel.org,
linux-kselftest@...r.kernel.org, rostedt@...dmis.org,
ryao@...too.org, dvhart@...radead.org, mingo@...hat.com,
z.figura12@...il.com, steven@...vesoftware.com,
steven@...uorix.net, malteskarupke@....de, carlos@...hat.com,
adhemerval.zanella@...aro.org, libc-alpha@...rceware.org,
linux-api@...r.kernel.org
Subject: Re: 'simple' futex interface [Was: [PATCH v3 1/4] futex: Implement mechanism to wait on any of several futexes]
* André Almeida:
> Thanks everyone for the feedback around our mechanism. Are the
> performance benefits of implementing a syscall to wait on a single futex
> significant enough to maintain it instead of just using
> `sys_futex_waitv()` with `nr_waiters = 1`? If we join both cases in a
> single interface, we may even add a new member for NUMA hint in `struct
> futex_wait`.
Some seccomp user might want to verify the address, and that's easier if
it's in an argument. But that's just a rather minor aspect.
Do you propose to drop the storage requirement for the NUMA hint
next to the futex completely?
Thanks,
Florian
Powered by blists - more mailing lists