From: André Almeida <hidden> Date: 2021-06-03 20:00:20
Hi,
This patch series introduces the futex2 syscalls.
* What happened to the current futex()?
For some years now, developers have been trying to add new features to
futex, but maintainers have been reluctant to accept then, given the
multiplexed interface full of legacy features and tricky to do big
changes. Some problems that people tried to address with patchsets are:
NUMA-awareness[0], smaller sized futexes[1], wait on multiple futexes[2].
NUMA, for instance, just doesn't fit the current API in a reasonable
way. Considering that, it's not possible to merge new features into the
current futex.
** The NUMA problem
At the current implementation, all futex kernel side infrastructure is
stored on a single node. Given that, all futex() calls issued by
processors that aren't located on that node will have a memory access
penalty when doing it.
** The 32bit sized futex problem
Futexes are used to implement atomic operations in userspace.
Supporting 8, 16, 32 and 64 bit sized futexes allows user libraries to
implement all those sizes in a performant way. Thanks Boost devs for
feedback: https://lists.boost.org/Archives/boost/2021/05/251508.php
Embedded systems or anything with memory constrains could benefit of
using smaller sizes for the futex userspace integer.
** The wait on multiple problem
The use case lies in the Wine implementation of the Windows NT interface
WaitMultipleObjects. This Windows API function allows a thread to sleep
waiting on the first of a set of event sources (mutexes, timers, signal,
console input, etc) to signal. Considering this is a primitive
synchronization operation for Windows applications, being able to quickly
signal events on the producer side, and quickly go to sleep on the
consumer side is essential for good performance of those running over Wine.
[0] https://lore.kernel.org/lkml/20160505204230.932454245@linutronix.de/
[1] https://lore.kernel.org/lkml/20191221155659.3159-2-malteskarupke@web.de/
[2] https://lore.kernel.org/lkml/20200213214525.183689-1-andrealmeid@collabora.com/
* The solution
As proposed by Peter Zijlstra and Florian Weimer[3], a new interface
is required to solve this, which must be designed with those features in
mind. futex2() is that interface. As opposed to the current multiplexed
interface, the new one should have one syscall per operation. This will
allow the maintainability of the API if it gets extended, and will help
users with type checking of arguments.
In particular, the new interface is extended to support the ability to
wait on any of a list of futexes at a time, which could be seen as a
vectored extension of the FUTEX_WAIT semantics.
[3] https://lore.kernel.org/lkml/20200303120050.GC2596@hirez.programming.kicks-ass.net/
* The interface
The new interface can be seen in details in the following patches, but
this is a high level summary of what the interface can do:
- Supports wake/wait semantics, as in futex()
- Supports requeue operations, similarly as FUTEX_CMP_REQUEUE, but with
individual flags for each address
- Supports waiting for a vector of futexes, using a new syscall named
futex_waitv()
- Supports variable sized futexes (8bits, 16bits, 32bits and 64bits)
- Supports NUMA-awareness operations, where the user can specify on
which memory node would like to operate
* Implementation
The internal implementation follows a similar design to the original futex.
Given that we want to replicate the same external behavior of current
futex, this should be somewhat expected. For some functions, like the
init and the code to get a shared key, I literally copied code and
comments from kernel/futex.c. I decided to do so instead of exposing the
original function as a public function since in that way we can freely
modify our implementation if required, without any impact on old futex.
Also, the comments precisely describes the details and corner cases of
the implementation.
Each patch contains a brief description of implementation, but patch 7
"docs: locking: futex2: Add documentation" adds a more complete document
about it.
* The patchset
This patchset can be also found at my git tree:
https://gitlab.collabora.com/tonyk/linux/-/tree/futex2-dev
- Patch 1: Implements wait/wake, and the basics foundations of futex2
- Patches 2-5: Implement the remaining features (shared, waitv,
requeue, sizes).
- Patch 6: Adds the x86_x32 ABI handling. I kept it in a separated
patch since I'm not sure if x86_x32 is still a thing, or if it should
return -ENOSYS.
- Patch 7: Add a documentation file which details the interface and
the internal implementation.
- Patches 8-14: Selftests for all operations along with perf
support for futex2.
- Patch 15: While working on porting glibc for futex2, I found out
that there's a futex_wake() call at the user thread exit path, if
that thread was created with clone(..., CLONE_CHILD_SETTID, ...). In
order to make pthreads work with futex2, it was required to add
this patch. Note that this is more a proof-of-concept of what we
will need to do in future, rather than part of the interface and
shouldn't be merged as it is.
* Testing:
This patchset provides selftests for each operation and their flags.
Along with that, the following work was done:
** Stability
To stress the interface in "real world scenarios":
- glibc[4]: nptl's low level locking was modified to use futex2 API
(except for robust and PI things). All relevant nptl/ tests passed.
- Wine[5]: Proton/Wine was modified in order to use futex2() for the
emulation of Windows NT sync mechanisms based on futex, called "fsync".
Triple-A games with huge CPU's loads and tons of parallel jobs worked
as expected when compared with the previous FUTEX_WAIT_MULTIPLE
implementation at futex(). Some games issue 42k futex2() calls
per second.
- Full GNU/Linux distro: I installed the modified glibc in my host
machine, so all pthread's programs would use futex2(). After tweaking
systemd[6] to allow futex2() calls at seccomp, everything worked as
expected (web browsers do some syscall sandboxing and need some
configuration as well).
- perf: The perf benchmarks tests can also be used to stress the
interface, and they can be found in this patchset.
** Performance
- For comparing futex() and futex2() performance, I used the artificial
benchmarks implemented at perf (wake, wake-parallel, hash and
requeue). The setup was 200 runs for each test and using 8, 80, 800,
8000 for the number of threads, Note that for this test, I'm not using
patch 14 ("kernel: Enable waitpid() for futex2") , for reasons explained
at "The patchset" section.
- For the first three ones, I measured an average of 4% gain in
performance. This is not a big step, but it shows that the new
interface is at least comparable in performance with the current one.
- For requeue, I measured an average of 21% decrease in performance
compared to the original futex implementation. This is expected given
the new design with individual flags. The performance trade-offs are
explained at patch 4 ("futex2: Implement requeue operation").
[4] https://gitlab.collabora.com/tonyk/glibc/-/tree/futex2
[5] https://gitlab.collabora.com/tonyk/wine/-/tree/proton_5.13
[6] https://gitlab.collabora.com/tonyk/systemd
* FAQ
** "Where's the code for NUMA?"
NUMA will be implemented in future versions of this patch, and like the
size feature, it will require work with users of futex to get feedback
about it.
** "Where's the PI/robust stuff?"
As said by Peter Zijlstra at [3], all those new features are related to
the "simple" futex interface, that doesn't use PI or robust. Do we want
to have this complexity at futex2() and if so, should it be part of
this patchset or can it be future work?
Thanks,
André
* Changelog
Changes from v3:
- Implemented variable sized futexes
v3: https://lore.kernel.org/lkml/20210427231248.220501-1-andrealmeid@collabora.com/
Changes from v2:
- API now supports 64bit futexes, in addition to 8, 16 and 32.
- This API change will break the glibc[4] and Proton[5] ports for now.
- Refactored futex2_wait and futex2_waitv selftests
v2: https://lore.kernel.org/lkml/20210304004219.134051-1-andrealmeid@collabora.com/
Changes from v1:
- Unified futex_set_timer_and_wait and __futex_wait code
- Dropped _carefull from linked list function calls
- Fixed typos on docs patch
- uAPI flags are now added as features are introduced, instead of all flags
in patch 1
- Removed struct futex_single_waiter in favor of an anon struct
v1: https://lore.kernel.org/lkml/20210215152404.250281-1-andrealmeid@collabora.com/
André Almeida (15):
futex2: Implement wait and wake functions
futex2: Add support for shared futexes
futex2: Implement vectorized wait
futex2: Implement requeue operation
futex2: Implement support for different futex sizes
futex2: Add compatibility entry point for x86_x32 ABI
docs: locking: futex2: Add documentation
selftests: futex2: Add wake/wait test
selftests: futex2: Add timeout test
selftests: futex2: Add wouldblock test
selftests: futex2: Add waitv test
selftests: futex2: Add requeue test
selftests: futex2: Add futex sizes test
perf bench: Add futex2 benchmark tests
kernel: Enable waitpid() for futex2
Documentation/locking/futex2.rst | 198 +++
Documentation/locking/index.rst | 1 +
MAINTAINERS | 2 +-
arch/arm/tools/syscall.tbl | 4 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 8 +
arch/x86/entry/syscalls/syscall_32.tbl | 4 +
arch/x86/entry/syscalls/syscall_64.tbl | 4 +
fs/inode.c | 1 +
include/linux/compat.h | 26 +
include/linux/fs.h | 1 +
include/linux/syscalls.h | 17 +
include/uapi/asm-generic/unistd.h | 14 +-
include/uapi/linux/futex.h | 34 +
init/Kconfig | 7 +
kernel/Makefile | 1 +
kernel/fork.c | 2 +
kernel/futex2.c | 1289 +++++++++++++++++
kernel/sys_ni.c | 9 +
tools/arch/x86/include/asm/unistd_64.h | 12 +
tools/include/uapi/asm-generic/unistd.h | 11 +-
.../arch/x86/entry/syscalls/syscall_64.tbl | 4 +
tools/perf/bench/bench.h | 4 +
tools/perf/bench/futex-hash.c | 24 +-
tools/perf/bench/futex-requeue.c | 57 +-
tools/perf/bench/futex-wake-parallel.c | 41 +-
tools/perf/bench/futex-wake.c | 37 +-
tools/perf/bench/futex.h | 47 +
tools/perf/builtin-bench.c | 18 +-
.../selftests/futex/functional/.gitignore | 4 +
.../selftests/futex/functional/Makefile | 7 +-
.../futex/functional/futex2_requeue.c | 164 +++
.../selftests/futex/functional/futex2_sizes.c | 146 ++
.../selftests/futex/functional/futex2_wait.c | 195 +++
.../selftests/futex/functional/futex2_waitv.c | 154 ++
.../futex/functional/futex_wait_timeout.c | 58 +-
.../futex/functional/futex_wait_wouldblock.c | 33 +-
.../testing/selftests/futex/functional/run.sh | 6 +
.../selftests/futex/include/futex2test.h | 113 ++
39 files changed, 2707 insertions(+), 52 deletions(-)
create mode 100644 Documentation/locking/futex2.rst
create mode 100644 kernel/futex2.c
create mode 100644 tools/testing/selftests/futex/functional/futex2_requeue.c
create mode 100644 tools/testing/selftests/futex/functional/futex2_sizes.c
create mode 100644 tools/testing/selftests/futex/functional/futex2_wait.c
create mode 100644 tools/testing/selftests/futex/functional/futex2_waitv.c
create mode 100644 tools/testing/selftests/futex/include/futex2test.h
--
2.31.1
From: André Almeida <hidden> Date: 2021-06-03 20:00:24
Create a new set of futex syscalls known as futex2. This new interface
is aimed to implement a more maintainable code, while removing obsolete
features and expanding it with new functionalities.
Implements wait and wake semantics for futexes, along with the base
infrastructure for future operations. The whole wait path is designed to
be used by N waiters, thus making easier to implement vectorized wait.
* Syscalls implemented by this patch:
- futex_wait(void *uaddr, unsigned int val, unsigned int flags,
struct timespec *timo)
The user thread is put to sleep, waiting for a futex_wake() at uaddr,
if the value at *uaddr is the same as val (otherwise, the syscall
returns immediately with -EAGAIN). timo is an optional timeout value
for the operation.
Return 0 on success, error code otherwise.
- futex_wake(void *uaddr, unsigned long nr_wake, unsigned int flags)
Wake `nr_wake` threads waiting at uaddr.
Return the number of woken threads on success, error code otherwise.
** The `flag` argument
The flag is used to specify the size of the futex word
(FUTEX_[8, 16, 32, 64]). It's mandatory to define one.
By default, the timeout uses a monotonic clock, but can be used as a
realtime one by using the FUTEX_REALTIME_CLOCK flag.
By default, futexes are of the private type, that means that this user
address will be accessed by threads that shares the same memory region.
This allows for some internal optimizations, so they are faster.
However, if the address needs to be shared with different processes
(like using `mmap()` or `shm()`), they need to be defined as shared and
the flag FUTEX_SHARED_FLAG is used to set that.
By default, the operation has no NUMA-awareness, meaning that the user
can't choose the memory node where the kernel side futex data will be
stored. The user can choose the node where it wants to operate by
setting the FUTEX_NUMA_FLAG and using the following structure (where X
can be 8, 16, or 32, 64):
struct futexX_numa {
__uX value;
__sX hint;
};
This structure should be passed at the `void *uaddr` of futex
functions. The address of the structure will be used to be waited/waken
on, and the `value` will be compared to `val` as usual. The `hint`
member is used to defined which node the futex will use. When waiting,
the futex will be registered on a kernel-side table stored on that
node; when waking, the futex will be searched for on that given table.
That means that there's no redundancy between tables, and the wrong
`hint` value will led to undesired behavior. Userspace is responsible
for dealing with node migrations issues that may occur. `hint` can
range from [0, MAX_NUMA_NODES], for specifying a node, or -1, to use
the same node the current process is using.
When not using FUTEX_NUMA_FLAG on a NUMA system, the futex will be
stored on a global table on some node, defined at compilation time.
** The `timo` argument
As per the Y2038 work done in the kernel, new interfaces shouldn't add
timeout options known to be buggy. Given that, `timo` should be a 64bit
timeout at all platforms, using an absolute timeout value.
Signed-off-by: André Almeida <redacted>
---
MAINTAINERS | 2 +-
arch/arm/tools/syscall.tbl | 2 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 4 +
arch/x86/entry/syscalls/syscall_32.tbl | 2 +
arch/x86/entry/syscalls/syscall_64.tbl | 2 +
include/linux/compat.h | 5 +
include/linux/syscalls.h | 6 +
include/uapi/asm-generic/unistd.h | 8 +-
include/uapi/linux/futex.h | 5 +
init/Kconfig | 7 +
kernel/Makefile | 1 +
kernel/futex2.c | 619 ++++++++++++++++++
kernel/sys_ni.c | 5 +
tools/include/uapi/asm-generic/unistd.h | 8 +-
.../arch/x86/entry/syscalls/syscall_64.tbl | 2 +
16 files changed, 676 insertions(+), 4 deletions(-)
create mode 100644 kernel/futex2.c
@@ -460,3 +460,5 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self+447 common futex_wait sys_futex_wait+448 common futex_wake sys_futex_wake
@@ -368,6 +368,8 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self+447 common futex_wait sys_futex_wait+448 common futex_wake sys_futex_wake # # Due to a historical design error, certain syscalls are numbered differently
@@ -0,0 +1,619 @@+// SPDX-License-Identifier: GPL-2.0-or-later+/*+*futex2systemcallinterfacebyAndréAlmeida<andrealmeid@collabora.com>+*+*Copyright2021CollaboraLtd.+*+*Basedonoriginalfuteximplementationby:+*(C)2002RustyRussell,IBM+*(C)2003,2006IngoMolnar,RedHatInc.+*(C)2003,2004JamieLokier+*(C)2006ThomasGleixner,TimesysCorp.+*(C)2007EricDumazet+*(C)2009DarrenHart,IBM+*/++#include<linux/freezer.h>+#include<linux/jhash.h>+#include<linux/memblock.h>+#include<linux/sched/wake_q.h>+#include<linux/spinlock.h>+#include<linux/syscalls.h>+#include<uapi/linux/futex.h>++/**+*structfutex_key-Componentstobuilduniquekeyforafutex+*@pointer:Pointertocurrent->mm+*@index:Startaddressofthepagecontainingfutex+*@offset:Addressoffsetofuaddrinapage+*/+structfutex_key{+u64pointer;+unsignedlongindex;+unsignedlongoffset;+};++/**+*structfutex_waiter-Listentryforawaiter+*@uaddr:Virtualaddressofuserspacefutex+*@key:Informationthatuniquelyidentifyafutex+*@list:Listnodestruct+*@val:Expectedvalueforthiswaiter+*@flags:Flags+*@bucket:Pointertothebucketforthiswaiter+*@index:Indexofwaiterinfutexvlist+*/+structfutex_waiter{+void__user*uaddr;+structfutex_keykey;+structlist_headlist;+u64val;+unsignedintflags;+structfutex_bucket*bucket;+unsignedintindex;+};++/**+*structfutex_waiter_head-Listoffutexestobewaited+*@task:Tasktobeawaken+*@hint:Wassomeoneonthislistawakened?+*@objects:Listoffutexes+*/+structfutex_waiter_head{+structtask_struct*task;+boolhint;+structfutex_waiterobjects[0];+};++/**+*structfutex_bucket-Abucketoffutex'shashtable+*@waiters:Numberofwaitersinthebucket+*@lock:Bucketlock+*@list:Listofwaitersonthisbucket+*/+structfutex_bucket{+atomic_twaiters;+spinlock_tlock;+structlist_headlist;+};++/* Mask for futex2 flag operations */+#define FUTEX2_MASK (FUTEX_SIZE_MASK | FUTEX_CLOCK_REALTIME)++staticstructfutex_bucket*futex_table;+staticunsignedintfutex2_hashsize;++/*+*Reflectsanewwaiterbeingaddedtothewaitqueue.+*/+staticinlinevoidbucket_inc_waiters(structfutex_bucket*bucket)+{+#ifdef CONFIG_SMP+atomic_inc(&bucket->waiters);+/*+*Issueabarrierafteraddingsofutex_wake()willseethatthe+*valuehadincreased+*/+smp_mb__after_atomic();+#endif+}++/*+*Reflectsawaiterbeingremovedfromthewaitqueuebywakeup+*paths.+*/+staticinlinevoidbucket_dec_waiters(structfutex_bucket*bucket)+{+#ifdef CONFIG_SMP+atomic_dec(&bucket->waiters);+#endif+}++/*+*Getthenumberofwaitersinabucket+*/+staticinlineintbucket_get_waiters(structfutex_bucket*bucket)+{+#ifdef CONFIG_SMP+/*+*Issueabarrierbeforereadingsowegetanupdatedvaluefrom+*futex_wait()+*/+smp_mb();+returnatomic_read(&bucket->waiters);+#else+return1;+#endif+}++/**+*futex_get_bucket-Checkiftheuseraddressisvalid,prepareinternal+*dataandcalculatethehash+*@uaddr:futexuseraddress+*@key:datathatuniquelyidentifiesafutex+*+*Return:addressofbucketonsuccess,errorcodeotherwise+*/+staticstructfutex_bucket*futex_get_bucket(void__user*uaddr,+structfutex_key*key)+{+uintptr_taddress=(uintptr_t)uaddr;+u32hash_key;++/* Checking if uaddr is valid and accessible */+if(unlikely(!IS_ALIGNED(address,sizeof(u32))))+returnERR_PTR(-EINVAL);+if(unlikely(!access_ok(uaddr,sizeof(u32))))+returnERR_PTR(-EFAULT);++key->offset=address%PAGE_SIZE;+address-=key->offset;+key->pointer=(u64)address;+key->index=(unsignedlong)current->mm;++/* Generate hash key for this futex using uaddr and current->mm */+hash_key=jhash2((u32*)key,sizeof(*key)/sizeof(u32),0);++/* Since HASH_SIZE is 2^n, subtracting 1 makes a perfect bit mask */+return&futex_table[hash_key&(futex2_hashsize-1)];+}++/**+*futex_get_user-Gettheuserspacevalueonthisaddress+*@uval:variabletostorethevalue+*@uaddr:userspaceaddress+*+*Checkthecommentatfutex_enqueue()formoreinformation.+*/+staticintfutex_get_user(u32*uval,u32__user*uaddr)+{+intret;++pagefault_disable();+ret=__get_user(*uval,uaddr);+pagefault_enable();++returnret;+}++/**+*futex_setup_time-Preparethetimeoutmechanismandstartit.+*@timo:Timeoutvaluefromuserspace+*@timeout:Pointertohrtimerhandler+*@flags:Flagsfromuserspace,todecidewhichclockidtouse+*+*Return:0onsuccess,errorcodeotherwise+*/+staticintfutex_setup_time(struct__kernel_timespec__user*timo,+structhrtimer_sleeper*timeout,+unsignedintflags)+{+ktime_ttime;+structtimespec64ts;+clockid_tclockid=(flags&FUTEX_CLOCK_REALTIME)?+CLOCK_REALTIME:CLOCK_MONOTONIC;++if(get_timespec64(&ts,timo))+return-EFAULT;++if(!timespec64_valid(&ts))+return-EINVAL;++time=timespec64_to_ktime(ts);++hrtimer_init_sleeper(timeout,clockid,HRTIMER_MODE_ABS);++hrtimer_set_expires(&timeout->timer,time);++hrtimer_sleeper_start_expires(timeout,HRTIMER_MODE_ABS);++return0;+}++/**+*futex_dequeue_multiple-Removemultiplefutexesfromhashtable+*@futexv:listofwaiters+*@nr:numberoffutexestoberemoved+*+*Thisfunctionisusedif(a)somethingwentwrongwhileenqueuing,andwe+*needtoundoourwork(thennr<=nr_futexes)or(b)wewokeup,andthus+*needtoremoveeverywaiter,checkifsomewasindeedwokenandreturn.+*Beforeremovingawaiter,wecheckifit'sonthelist,sincewehaveno+*cluewhohavebeenwaken.+*+*Return:+**-1-Ifnofutexwaswokenduringtheremoval+**0>=-Atleastonefutexwasfoundwoken,indexofthelastone+*/+staticintfutex_dequeue_multiple(structfutex_waiter_head*futexv,unsignedintnr)+{+inti,ret=-1;++for(i=0;i<nr;i++){+spin_lock(&futexv->objects[i].bucket->lock);+if(!list_empty(&futexv->objects[i].list)){+list_del_init(&futexv->objects[i].list);+bucket_dec_waiters(futexv->objects[i].bucket);+}else{+ret=i;+}+spin_unlock(&futexv->objects[i].bucket->lock);+}++returnret;+}++/**+*futex_enqueue-Checkthevalueandenqueueafutexonawaitlist+*+*@futexv:Listoffutexes+*@nr_futexes:Numberoffutexesinthelist+*@awakened:Ifafutexwasawakenedduringenqueueing,storetheindexhere+*+*Getthevaluefromtheuserspaceaddressandcompareswiththeexpectedone.+*+*Gettingthevaluefromuserfutexaddress:+*+*Sinceweareinahurry,weuseaspinlockandwecan'tsleep.+*Trytogetthevaluewithpagefaultdisabled(whenenable,wemight+*sleep).+*+*Ifwefail,wearen'tsureiftheaddressisinvalidorisjusta+*pagefault.Then,releasethelock(sowecansleep)andtrytoget+*thevaluewithpagefaultenabled.Inordertotriggerapagefault+*handling,wejustcall__get_user()again.Ifwesleepwithenqueued+*futexes,wemightmissawake,sodequeueeverythingbeforesleeping.+*+*Ifget_usersucceeds,thismeanthattheaddressisvalidandwedo+*theworkagain.Sincewejusthandledthepagefault,thepageis+*likelypinnedinmemoryandweshouldbeluckierthistimeandbe+*abletogetthevalue.Ifwefailanyway,wewilltryagain.+*+*Ifevenwithpagefaultsenabledwegetanderror,thismeansthat+*theaddressisnotvalidandwereturnfromthesyscall.+*+*Ifwegotanunexpectedvalueorneedtotreatapagefaultandrealizedthat+*afutexwasawakened,wecanprioritythisandreturnsuccess.+*+*Insuccess,enqueuethefutexinthecorrectbucket+*+*Return:+**1-Wewereawakeintheprocessandnothingisenqueued+**0-Everythingisenqueuedandwearereadytosleep+**0<-Somethingwentwrong,nothingisenqueued,returnerrorcode+*/+staticintfutex_enqueue(structfutex_waiter_head*futexv,unsignedintnr_futexes,+int*awakened)+{+inti,ret;+u32uval,val;+u32__user*uaddr;+structfutex_bucket*bucket;++retry:+set_current_state(TASK_INTERRUPTIBLE);++for(i=0;i<nr_futexes;i++){+uaddr=(u32__user*)futexv->objects[i].uaddr;+val=(u32)futexv->objects[i].val;++bucket=futexv->objects[i].bucket;++bucket_inc_waiters(bucket);+spin_lock(&bucket->lock);++ret=futex_get_user(&uval,uaddr);++if(unlikely(ret)){+spin_unlock(&bucket->lock);++bucket_dec_waiters(bucket);+__set_current_state(TASK_RUNNING);+*awakened=futex_dequeue_multiple(futexv,i);++if(*awakened>=0)+return1;++if(__get_user(uval,uaddr))+return-EFAULT;++gotoretry;+}++if(uval!=val){+spin_unlock(&bucket->lock);++bucket_dec_waiters(bucket);+__set_current_state(TASK_RUNNING);+*awakened=futex_dequeue_multiple(futexv,i);++if(*awakened>=0)+return1;++return-EAGAIN;+}++list_add_tail(&futexv->objects[i].list,&bucket->list);+spin_unlock(&bucket->lock);+}++return0;+}++/**+*__futex_waitv-Enqueuethelistoffutexesandwaittobewoken+*@futexv:Listoffutexestowait+*@nr_futexes:Lengthoffutexv+*@timo:Timeout+*@flags:Timeoutflags+*+*Return:+**0>=-Hintofwhichfutexwokeus+**0<-Errorcode+*/+staticint__futex_waitv(structfutex_waiter_head*futexv,unsignedintnr_futexes,+struct__kernel_timespec__user*timo,+unsignedintflags)+{+intret;+structhrtimer_sleepertimeout;++if(timo){+ret=futex_setup_time(timo,&timeout,flags);+if(ret)+returnret;+}++while(1){+intawakened=-1;++ret=futex_enqueue(futexv,nr_futexes,&awakened);++if(ret){+if(awakened>=0)+ret=awakened;+break;+}++/* Before sleeping, check if someone was woken */+if(!futexv->hint&&(!timo||timeout.task))+freezable_schedule();++__set_current_state(TASK_RUNNING);++/*+*Oneofthosethingstriggeredthiswake:+*+**Wehavebeenremovedfromthebucket.futex_wake()woke+*us.Wejustneedtodequeueandreturn0touserspace.+*+*However,ifnofutexwasdequeuedbyafutex_wake():+*+**Ifthethere'satimeoutandithasexpired,+*return-ETIMEDOUT.+*+**Ifthereisasignalpending,somethingwantstokillour+*thread,return-ERESTARTSYS.+*+**Ifthere'snosignalpending,itwasaspuriouswake+*(schedulergaveusachancetodosomework,evenifwe+*don'twantto).Weneedtoremoveourselvesfromthe+*bucketandaddagain,topreventlosingwakeupsinthe+*meantime.+*/++ret=futex_dequeue_multiple(futexv,nr_futexes);++/* Normal wake */+if(ret>=0)+break;++if(timo&&!timeout.task){+ret=-ETIMEDOUT;+break;+}++if(signal_pending(current)){+ret=-ERESTARTSYS;+break;+}++/* Spurious wake, do everything again */+}++if(timo)+hrtimer_cancel(&timeout.timer);++returnret;+}++staticlongksys_futex_wait(void__user*uaddr,u64val,unsignedintflags,+struct__kernel_timespec__user*timo)+{+unsignedintsize=flags&FUTEX_SIZE_MASK;+structfutex_waiter*waiter;+structfutex_waiter_head*futexv;++/* Wrapper for a futexv_waiter_head with one element */+struct{+structfutex_waiter_headfutexv;+structfutex_waiterwaiter;+}__packedwait_single;++if(flags&~FUTEX2_MASK)+return-EINVAL;++if(size!=FUTEX_32)+return-EINVAL;++futexv=&wait_single.futexv;+futexv->task=current;+futexv->hint=false;++waiter=&wait_single.waiter;+waiter->index=0;+waiter->val=val;+waiter->uaddr=uaddr;+memset(&wait_single.waiter.key,0,sizeof(structfutex_key));++INIT_LIST_HEAD(&waiter->list);++/* Get an unlocked hash bucket */+waiter->bucket=futex_get_bucket(uaddr,&waiter->key);+if(IS_ERR(waiter->bucket))+returnPTR_ERR(waiter->bucket);++return__futex_waitv(futexv,1,timo,flags);+}++#ifdef CONFIG_COMPAT+COMPAT_SYSCALL_DEFINE4(compat_futex_wait,void__user*,uaddr,compat_u64,val,+unsignedint,flags,+struct__kernel_timespec__user*,timo)+{+returnksys_futex_wait(uaddr,val,flags,timo);+}+#endif++/**+*sys_futex_wait-Waitonafutexaddressif(*uaddr)==val+*@uaddr:Useraddressoffutex+*@val:Expectedvalueoffutex+*@flags:Specifythesizeoffutexandtheclockid+*@timo:Optionalabsolutetimeout.+*+*Theuserthreadisputtosleep,waitingforafutex_wake()atuaddr,ifthe+*valueat*uaddristhesameasval(otherwise,thesyscallreturns+*immediatelywith-EAGAIN).+*+*Returns0onsuccess,errorcodeotherwise.+*/+SYSCALL_DEFINE4(futex_wait,void__user*,uaddr,u64,val,unsignedint,flags,+struct__kernel_timespec__user*,timo)+{++returnksys_futex_wait(uaddr,val,flags,timo);+}++/**+*futex_get_parent-Foragivenfutexinafutexvlist,getapointertothefutexv+*@waiter:Addressoffutexinthelist+*@index:Indexoffutexinthelist+*+*Return:Apointertoitsfutexvstruct+*/+staticinlinestructfutex_waiter_head*futex_get_parent(uintptr_twaiter,+unsignedintindex)+{+uintptr_tparent=waiter-sizeof(structfutex_waiter_head)+-(uintptr_t)(index*sizeof(structfutex_waiter));++return(structfutex_waiter_head*)parent;+}++/**+*futex_mark_wake-Findthetasktobewakeandadditinwakequeue+*@waiter:Waitertobewake+*@bucket:Buckettobedecremented+*@wake_q:Wakequeuetoinsertthetask+*/+staticvoidfutex_mark_wake(structfutex_waiter*waiter,+structfutex_bucket*bucket,+structwake_q_head*wake_q)+{+structtask_struct*task;+structfutex_waiter_head*parent=futex_get_parent((uintptr_t)waiter,+waiter->index);++lockdep_assert_held(&bucket->lock);+parent->hint=true;+task=parent->task;+get_task_struct(task);+list_del_init(&waiter->list);+wake_q_add_safe(wake_q,task);+bucket_dec_waiters(bucket);+}++staticinlineboolfutex_match(structfutex_keykey1,structfutex_keykey2)+{+return(key1.index==key2.index&&+key1.pointer==key2.pointer&&+key1.offset==key2.offset);+}++/**+*sys_futex_wake-Wakeanumberoffutexeswaitingonanaddress+*@uaddr:Addressoffutextobewokenup+*@nr_wake:Numberoffutexeswaitinginuaddrtobewokenup+*@flags:Flagsforsizeandshared+*+*Wake`nr_wake`threadswaitingatuaddr.+*+*Returnsthenumberofwokenthreadsonsuccess,errorcodeotherwise.+*/+SYSCALL_DEFINE3(futex_wake,void__user*,uaddr,unsignedint,nr_wake,+unsignedint,flags)+{+unsignedintsize=flags&FUTEX_SIZE_MASK;+structfutex_waiterwaiter,*aux,*tmp;+structfutex_bucket*bucket;+DEFINE_WAKE_Q(wake_q);+intret=0;++if(flags&~FUTEX2_MASK)+return-EINVAL;++if(size!=FUTEX_32)+return-EINVAL;++bucket=futex_get_bucket(uaddr,&waiter.key);+if(IS_ERR(bucket))+returnPTR_ERR(bucket);++if(!bucket_get_waiters(bucket)||!nr_wake)+return0;++spin_lock(&bucket->lock);+list_for_each_entry_safe(aux,tmp,&bucket->list,list){+if(futex_match(waiter.key,aux->key)){+futex_mark_wake(aux,bucket,&wake_q);+if(++ret>=nr_wake)+break;+}+}+spin_unlock(&bucket->lock);++wake_up_q(&wake_q);++returnret;+}++staticint__initfutex2_init(void)+{+inti;+unsignedintfutex_shift;++#if CONFIG_BASE_SMALL+futex2_hashsize=16;+#else+futex2_hashsize=roundup_pow_of_two(256*num_possible_cpus());+#endif++futex_table=alloc_large_system_hash("futex2",sizeof(structfutex_bucket),+futex2_hashsize,0,+futex2_hashsize<256?HASH_SMALL:0,+&futex_shift,NULL,+futex2_hashsize,futex2_hashsize);+futex2_hashsize=1UL<<futex_shift;++BUG_ON(!is_power_of_2(futex2_hashsize));++for(i=0;i<futex2_hashsize;i++){+INIT_LIST_HEAD(&futex_table[i].list);+spin_lock_init(&futex_table[i].lock);+atomic_set(&futex_table[i].waiters,0);+}++return0;+}+core_initcall(futex2_init);
@@ -368,6 +368,8 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self+447 common futex_wait sys_futex_wait+448 common futex_wake sys_futex_wake # # Due to a historical design error, certain syscalls are numbered differently
From: André Almeida <hidden> Date: 2021-06-03 20:00:29
Add support for shared futexes for cross-process resources. This design
relies on the same approach done in old futex to create an unique id for
file-backed shared memory, by using a counter at struct inode.
There are two types of futexes: private and shared ones. The private are
futexes meant to be used by threads that shares the same memory space,
are easier to be uniquely identified an thus can have some performance
optimization. The elements for identifying one are: the start address of
the page where the address is, the address offset within the page and
the current->mm pointer.
Now, for uniquely identifying shared futex:
- If the page containing the user address is an anonymous page, we can
just use the same data used for private futexes (the start address of
the page, the address offset within the page and the current->mm
pointer) that will be enough for uniquely identifying such futex. We
also set one bit at the key to differentiate if a private futex is
used on the same address (mixing shared and private calls are not
allowed).
- If the page is file-backed, current->mm maybe isn't the same one for
every user of this futex, so we need to use other data: the
page->index, an UUID for the struct inode and the offset within the
page.
Note that members of futex_key doesn't have any particular meaning after
they are part of the struct - they are just bytes to identify a futex.
Given that, we don't need to use a particular name or type that matches
the original data, we only need to care about the bitsize of each
component and make both private and shared data fit in the same memory
space.
Signed-off-by: André Almeida <redacted>
---
fs/inode.c | 1 +
include/linux/fs.h | 1 +
include/uapi/linux/futex.h | 2 +
kernel/futex2.c | 221 +++++++++++++++++++++++++++++++++++--
4 files changed, 218 insertions(+), 7 deletions(-)
@@ -78,7 +80,12 @@ struct futex_bucket {};/* Mask for futex2 flag operations */-#define FUTEX2_MASK (FUTEX_SIZE_MASK | FUTEX_CLOCK_REALTIME)+#define FUTEX2_MASK (FUTEX_SIZE_MASK | FUTEX_CLOCK_REALTIME | FUTEX_SHARED_FLAG)++#define is_object_shared ((futexv->objects[i].flags & FUTEX_SHARED_FLAG) ? true : false)++#define FUT_OFF_INODE 1 /* We set bit 0 if key has a reference on inode */+#define FUT_OFF_MMSHARED 2 /* We set bit 1 if key has a reference on mm */staticstructfutex_bucket*futex_table;staticunsignedintfutex2_hashsize;
@@ -126,16 +133,198 @@ static inline int bucket_get_waiters(struct futex_bucket *bucket)#endif}+/**+*futex_get_inode_uuid-GetsanUUIDforaninode+*@inode:inodetogetUUID+*+*Generateamachinewideuniqueidentifierforthisinode.+*+*Thisreliesonu64notwrappinginthelife-timeofthemachine;whichwith+*1nsresolutionmeansalmost585years.+*+*Thisfurtherreliesonthefactthatawellformedprogramwillnotunmap+*thefilewhileithasa(shared)futexwaitingonit.Thismappingwillhave+*afilereferencewhichpinsthemountandinode.+*+*Ifforsomereasonaninodegetsevictedandreadbackinagain,itwillget+*anewsequencenumberandwill_NOT_match,eventhoughitistheexactsame+*file.+*+*Itisimportantthatmatch_futex()willneverhaveafalse-positive,esp.+*forPIfutexesthatcanmessupthestate.Theabovearguesthatfalse-negatives+*areonlypossibleformalformedprograms.+*+*Returns:UUIDforthegiveninode+*/+staticu64futex_get_inode_uuid(structinode*inode)+{+staticatomic64_ti_seq;+u64old;++/* Does the inode already have a sequence number? */+old=atomic64_read(&inode->i_sequence2);++if(likely(old))+returnold;++for(;;){+u64new=atomic64_add_return(1,&i_seq);++if(WARN_ON_ONCE(!new))+continue;++old=atomic64_cmpxchg_relaxed(&inode->i_sequence2,0,new);+if(old)+returnold;+returnnew;+}+}++/**+*futex_get_shared_key-Getakeyforasharedfutex+*@address:Futexmemoryaddress+*@mm:Currentprocessmm_structpointer+*@key:Keystructtobefilled+*+*Returns:0onsuccess,errorcodeotherwise+*/+staticintfutex_get_shared_key(uintptr_taddress,structmm_struct*mm,+structfutex_key*key)+{+intret;+structpage*page,*tail;+structaddress_space*mapping;++again:+ret=get_user_pages_fast(address,1,0,&page);+if(ret<0)+returnret;++/*+*Thetreatmentofmappingfromthispointoniscritical.Thepage+*lockprotectsmanythingsbutinthiscontextthepagelock+*stabilizesmapping,preventsinodefreeingintheshared+*file-backedregioncaseandguardsagainstmovementtoswapcache.+*+*Strictlyspeakingthepagelockisnotneededinallcasesbeing+*consideredhereandpagelockforcesunnecessarilyserialization+*Fromthispointon,mappingwillbere-verifiedifnecessaryand+*pagelockwillbeacquiredonlyifitisunavoidable+*+*Mappingchecksrequiretheheadpageforanycompoundpagesothe+*headpageandmappingislookedupnow.Foranonymouspages,it+*doesnotmatterifthepagesplitsinthefutureasthekeyis+*basedontheaddress.Forfilesystem-backedpages,thetailis+*requiredastheindexofthepagedeterminesthekey.For+*basepages,thereisnotailpageandtail==page.+*/+tail=page;+page=compound_head(page);+mapping=READ_ONCE(page->mapping);++/*+*Ifpage->mappingisNULL,thenitcannotbeaPageAnon+*page;butitmightbetheZERO_PAGEorinthegateareaor+*inaspecialmapping(allcaseswhichwearehappytofail);+*oritmayhavebeenagoodfilepagewhenget_user_pages_fast+*foundit,buttruncatedorholepunchedorsubjectedto+*invalidate_complete_page2beforewegotthepagelock(also+*caseswhichwearehappytofail).Andweholdareference,+*sorefcountcareininvalidate_complete_page'sremove_mapping+*preventsdrop_cachesfromsettingmappingtoNULLbeneathus.+*+*Thecasewedohavetoguardagainstiswhenmemorypressuremade+*shmem_writepagemoveitfromfilecachetoswapcachebeneathus:+*anunlikelyrace,butwedoneedtoretryforpage->mapping.+*/+if(unlikely(!mapping)){+intshmem_swizzled;++/*+*Pagelockisrequiredtoidentifywhichspecialcaseabove+*applies.Ifthisisreallyashmempagethenthepagelock+*willpreventunexpectedtransitions.+*/+lock_page(page);+shmem_swizzled=PageSwapCache(page)||page->mapping;+unlock_page(page);+put_page(page);++if(shmem_swizzled)+gotoagain;++return-EFAULT;+}++/*+*Ifthefutexkeyisstoredonananonymouspage,thentheassociated+*objectisthemmwhichisimplicitlypinnedbythecallingprocess.+*+*NOTE:WhenuserspacewaitsonaMAP_SHAREDmapping,evenif+*it'saread-onlyhandle,it'sexpectedthatfutexesattachto+*theobjectnottheparticularprocess.+*/+if(PageAnon(page)){+key->offset|=FUT_OFF_MMSHARED;+}else{+structinode*inode;++/*+*Theassociatedfutexobjectinthiscaseistheinodeand+*thepage->mappingmustbetraversed.Ordinarilythisshould+*bestabilisedunderpagelockbutit'snotstrictly+*necessaryinthiscaseaswejustwanttopintheinode,not+*updatetheradixtreeoranythinglikethat.+*+*TheRCUreadlockistakenastheinodeisfinallyfreed+*underRCU.Ifthemappingstillmatchesexpectationsthenthe+*mapping->hostcanbesafelyaccessedasbeingavalidinode.+*/+rcu_read_lock();++if(READ_ONCE(page->mapping)!=mapping){+rcu_read_unlock();+put_page(page);++gotoagain;+}++inode=READ_ONCE(mapping->host);+if(!inode){+rcu_read_unlock();+put_page(page);++gotoagain;+}++key->pointer=futex_get_inode_uuid(inode);+key->index=(unsignedlong)basepage_index(tail);+key->offset|=FUT_OFF_INODE;++rcu_read_unlock();+}++put_page(page);++return0;+}+/***futex_get_bucket-Checkiftheuseraddressisvalid,prepareinternal*dataandcalculatethehash*@uaddr:futexuseraddress*@key:datathatuniquelyidentifiesafutex+*@shared:isthisasharedfutex?+*+*Forprivatefutexes,eachuaddrwillbeuniqueforagivenmm_struct,andit+*won'tbefreedforthelifetimeoftheprocess.Forsharedfutexes,check+*futex_get_shared_key().**Return:addressofbucketonsuccess,errorcodeotherwise*/staticstructfutex_bucket*futex_get_bucket(void__user*uaddr,-structfutex_key*key)+structfutex_key*key,+boolshared){uintptr_taddress=(uintptr_t)uaddr;u32hash_key;
@@ -151,6 +340,9 @@ static struct futex_bucket *futex_get_bucket(void __user *uaddr,key->pointer=(u64)address;key->index=(unsignedlong)current->mm;+if(shared)+futex_get_shared_key(address,current->mm,key);+/* Generate hash key for this futex using uaddr and current->mm */hash_key=jhash2((u32*)key,sizeof(*key)/sizeof(u32),0);
@@ -288,6 +480,7 @@ static int futex_enqueue(struct futex_waiter_head *futexv, unsigned int nr_futexinti,ret;u32uval,val;u32__user*uaddr;+boolretry=false;structfutex_bucket*bucket;retry:
@@ -297,6 +490,18 @@ static int futex_enqueue(struct futex_waiter_head *futexv, unsigned int nr_futexuaddr=(u32__user*)futexv->objects[i].uaddr;val=(u32)futexv->objects[i].val;+if(is_object_shared&&retry){+structfutex_bucket*tmp=+futex_get_bucket((void__user*)uaddr,+&futexv->objects[i].key,true);+if(IS_ERR(tmp)){+__set_current_state(TASK_RUNNING);+futex_dequeue_multiple(futexv,i);+returnPTR_ERR(tmp);+}+futexv->objects[i].bucket=tmp;+}+bucket=futexv->objects[i].bucket;bucket_inc_waiters(bucket);
@@ -317,6 +522,7 @@ static int futex_enqueue(struct futex_waiter_head *futexv, unsigned int nr_futexif(__get_user(uval,uaddr))return-EFAULT;+retry=true;gotoretry;}
@@ -430,6 +636,7 @@ static int __futex_waitv(struct futex_waiter_head *futexv, unsigned int nr_futexstaticlongksys_futex_wait(void__user*uaddr,u64val,unsignedintflags,struct__kernel_timespec__user*timo){+boolshared=(flags&FUTEX_SHARED_FLAG)?true:false;unsignedintsize=flags&FUTEX_SIZE_MASK;structfutex_waiter*waiter;structfutex_waiter_head*futexv;
@@ -459,7 +666,7 @@ static long ksys_futex_wait(void __user *uaddr, u64 val, unsigned int flags,INIT_LIST_HEAD(&waiter->list);/* Get an unlocked hash bucket */-waiter->bucket=futex_get_bucket(uaddr,&waiter->key);+waiter->bucket=futex_get_bucket(uaddr,&waiter->key,shared);if(IS_ERR(waiter->bucket))returnPTR_ERR(waiter->bucket);
From: André Almeida <hidden> Date: 2021-06-03 20:00:33
Add support to wait on multiple futexes. This is the interface
implemented by this syscall:
futex_waitv(struct futex_waitv *waiters, unsigned int nr_futexes,
unsigned int flags, struct timespec *timo)
struct futex_waitv {
__u64 val;
void *uaddr;
unsigned int flags;
};
Given an array of struct futex_waitv, wait on each uaddr. The thread
wakes if a futex_wake() is performed at any uaddr. The syscall returns
immediately if any waiter has *uaddr != val. *timo is an optional
timeout value for the operation. The flags argument of the syscall
should be used solely for specifying the timeout as realtime, if needed.
Flags for shared futexes, sizes, etc. should be used on the individual
flags of each waiter.
Returns the array index of one of the awakened futexes. There’s no given
information of how many were awakened, or any particular attribute of it
(if it’s the first awakened, if it is of the smaller index...).
Signed-off-by: André Almeida <redacted>
---
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
include/linux/compat.h | 9 +
include/linux/syscalls.h | 4 +
include/uapi/asm-generic/unistd.h | 5 +-
include/uapi/linux/futex.h | 14 ++
kernel/futex2.c | 177 ++++++++++++++++++
kernel/sys_ni.c | 2 +
tools/include/uapi/asm-generic/unistd.h | 5 +-
.../arch/x86/entry/syscalls/syscall_64.tbl | 1 +
13 files changed, 221 insertions(+), 3 deletions(-)
@@ -462,3 +462,4 @@ 446 common landlock_restrict_self sys_landlock_restrict_self 447 common futex_wait sys_futex_wait 448 common futex_wake sys_futex_wake+449 common futex_waitv sys_futex_waitv
@@ -370,6 +370,7 @@ 446 common landlock_restrict_self sys_landlock_restrict_self 447 common futex_wait sys_futex_wait 448 common futex_wake sys_futex_wake+449 common futex_waitv sys_futex_waitv # # Due to a historical design error, certain syscalls are numbered differently
@@ -82,6 +82,12 @@ struct futex_bucket {/* Mask for futex2 flag operations */#define FUTEX2_MASK (FUTEX_SIZE_MASK | FUTEX_CLOCK_REALTIME | FUTEX_SHARED_FLAG)+/* Mask for sys_futex_waitv flag */+#define FUTEXV_MASK (FUTEX_CLOCK_REALTIME)++/* Mask for each futex in futex_waitv list */+#define FUTEXV_WAITER_MASK (FUTEX_SIZE_MASK | FUTEX_SHARED_FLAG)+#define is_object_shared ((futexv->objects[i].flags & FUTEX_SHARED_FLAG) ? true : false)#define FUT_OFF_INODE 1 /* We set bit 0 if key has a reference on inode */
@@ -370,6 +370,7 @@ 446 common landlock_restrict_self sys_landlock_restrict_self 447 common futex_wait sys_futex_wait 448 common futex_wake sys_futex_wake+449 common futex_waitv sys_futex_waitv # # Due to a historical design error, certain syscalls are numbered differently
From: André Almeida <hidden> Date: 2021-06-03 20:00:41
Implement requeue interface similarly to FUTEX_CMP_REQUEUE operation.
This is the syscall implemented by this patch:
futex_requeue(struct futex_requeue *uaddr1, struct futex_requeue *uaddr2,
unsigned int nr_wake, unsigned int nr_requeue,
u64 cmpval, unsigned int flags)
struct futex_requeue {
void *uaddr;
unsigned int flags;
};
If (uaddr1->uaddr == cmpval), wake at uaddr1->uaddr a nr_wake number of
waiters and then, remove a number of nr_requeue waiters at uaddr1->uaddr
and add them to uaddr2->uaddr list. Each uaddr has its own set of flags,
that must be defined at struct futex_requeue (such as size, shared, NUMA).
The flags argument of the syscall is there just for the sake of
extensibility, and right now it needs to be zero.
Return the number of the woken futexes + the number of requeued ones on
success, error code otherwise.
Signed-off-by: André Almeida <redacted>
---
The original FUTEX_CMP_REQUEUE interfaces is such as follows:
futex(*uaddr1, FUTEX_CMP_REQUEUE, nr_wake, nr_requeue, *uaddr2, cmpval);
Given that when this interface was created they was only one type of
futex (as opposed to futex2, where there is shared, sizes, and NUMA),
there was no way to specify individual flags for uaddr1 and 2. When
FUTEX_PRIVATE was implemented, a new opcode was created as well
(FUTEX_CMP_REQUEUE_PRIVATE), but they apply both futexes, so they
should be of the same type regarding private/shared. This imposes a
limitation on the use cases of the operation, and to overcome that at futex2,
`struct futex_requeue` was created, so one can set individual flags for
each futex. This flexibility is a trade-off with performance, given that
now we need to perform two extra copy_from_user(). One alternative would
be to use the upper half of flags bits to the first one, and the bottom
half for the second futex, but this would also impose limitations, given
that we would limit by half the flags possibilities. If equal futexes
are common enough, the following extension could be added to overcome
the current performance:
- A flag FUTEX_REQUEUE_EQUAL is added to futex2() flags;
- If futex_requeue() see this flag, that means that both futexes uses
the same set of attributes.
- Then, the function parses the flags as of futex_wait/wake().
- *uaddr1 and *uaddr2 are used as void* (instead of struct
futex_requeue) just like wait/wake().
In that way, we could avoid the copy_from_user().
---
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
include/linux/compat.h | 12 +
include/linux/syscalls.h | 5 +
include/uapi/asm-generic/unistd.h | 5 +-
include/uapi/linux/futex.h | 10 +
kernel/futex2.c | 208 ++++++++++++++++++
kernel/sys_ni.c | 2 +
.../arch/x86/entry/syscalls/syscall_64.tbl | 1 +
12 files changed, 248 insertions(+), 2 deletions(-)
@@ -463,3 +463,4 @@ 447 common futex_wait sys_futex_wait 448 common futex_wake sys_futex_wake 449 common futex_waitv sys_futex_waitv+450 common futex_requeue sys_futex_requeue
@@ -371,6 +371,7 @@ 447 common futex_wait sys_futex_wait 448 common futex_wake sys_futex_wake 449 common futex_waitv sys_futex_waitv+450 common futex_requeue sys_futex_requeue # # Due to a historical design error, certain syscalls are numbered differently
@@ -371,6 +371,7 @@ 447 common futex_wait sys_futex_wait 448 common futex_wake sys_futex_wake 449 common futex_waitv sys_futex_waitv+450 common futex_requeue sys_futex_requeue # # Due to a historical design error, certain syscalls are numbered differently
From: André Almeida <hidden> Date: 2021-06-03 20:00:52
Implement support for 8, 16 and 64 bit futexes, along with the existing
32 bit support. Userspace should use flags to specify in the syscall
the size of the *uaddr they are operating on.
Variable sized futexes are useful for implementing atomic primitives in
userspace in an efficient manner. 64bit sized futexes are also
particularly useful when userspace stores information to be used in an
atomic fashion on the futex value, given more room for flexibility.
Overlapping futexes are not allowed, so userspace can't wait and wake on
the same memory address if the are using different sizes.
Signed-off-by: André Almeida <redacted>
---
include/uapi/linux/futex.h | 3 +
kernel/futex2.c | 124 ++++++++++++++++++++++++-------------
2 files changed, 84 insertions(+), 43 deletions(-)
@@ -89,9 +89,11 @@ struct futex_bucket {#define FUTEXV_WAITER_MASK (FUTEX_SIZE_MASK | FUTEX_SHARED_FLAG)#define is_object_shared ((futexv->objects[i].flags & FUTEX_SHARED_FLAG) ? true : false)+#define object_size (futexv->objects[i].flags & FUTEX_SIZE_MASK)-#define FUT_OFF_INODE 1 /* We set bit 0 if key has a reference on inode */-#define FUT_OFF_MMSHARED 2 /* We set bit 1 if key has a reference on mm */+#define FUT_OFF_INODE PAGE_SIZE+#define FUT_OFF_MMSHARED (PAGE_SIZE << 1)+#define FUT_OFF_SIZE 1staticstructfutex_bucket*futex_table;staticunsignedintfutex2_hashsize;
@@ -330,21 +333,41 @@ static int futex_get_shared_key(uintptr_t address, struct mm_struct *mm,*/staticstructfutex_bucket*futex_get_bucket(void__user*uaddr,structfutex_key*key,-boolshared)+boolshared,unsignedintflags){uintptr_taddress=(uintptr_t)uaddr;u32hash_key;+size_tsize;++switch(flags){+caseFUTEX_8:+size=sizeof(u8);+break;+caseFUTEX_16:+size=sizeof(u16);+break;+caseFUTEX_32:+size=sizeof(u32);+break;+caseFUTEX_64:+size=sizeof(u64);+break;+default:+returnERR_PTR(-EINVAL);+}+/* Checking if uaddr is valid and accessible */-if(unlikely(!IS_ALIGNED(address,sizeof(u32))))+if(unlikely(!IS_ALIGNED(address,size)))returnERR_PTR(-EINVAL);-if(unlikely(!access_ok(uaddr,sizeof(u32))))+if(unlikely(!access_ok(uaddr,size)))returnERR_PTR(-EFAULT);key->offset=address%PAGE_SIZE;address-=key->offset;key->pointer=(u64)address;key->index=(unsignedlong)current->mm;+key->offset|=FUT_OFF_SIZE<<(size-sizeof(u8));if(shared)futex_get_shared_key(address,current->mm,key);
@@ -484,8 +528,8 @@ static int futex_enqueue(struct futex_waiter_head *futexv, unsigned int nr_futexint*awakened){inti,ret;-u32uval,val;-u32__user*uaddr;+u64uval,val;+void__user*uaddr;boolretry=false;structfutex_bucket*bucket;
@@ -493,13 +537,14 @@ static int futex_enqueue(struct futex_waiter_head *futexv, unsigned int nr_futexset_current_state(TASK_INTERRUPTIBLE);for(i=0;i<nr_futexes;i++){-uaddr=(u32__user*)futexv->objects[i].uaddr;-val=(u32)futexv->objects[i].val;+uaddr=futexv->objects[i].uaddr;+val=(u64)futexv->objects[i].val;if(is_object_shared&&retry){structfutex_bucket*tmp=futex_get_bucket((void__user*)uaddr,-&futexv->objects[i].key,true);+&futexv->objects[i].key,true,+object_size);if(IS_ERR(tmp)){__set_current_state(TASK_RUNNING);futex_dequeue_multiple(futexv,i);
@@ -513,7 +558,7 @@ static int futex_enqueue(struct futex_waiter_head *futexv, unsigned int nr_futexbucket_inc_waiters(bucket);spin_lock(&bucket->lock);-ret=futex_get_user(&uval,uaddr);+ret=futex_get_user(&uval,uaddr,object_size,true);if(unlikely(ret)){spin_unlock(&bucket->lock);
@@ -525,7 +570,7 @@ static int futex_enqueue(struct futex_waiter_head *futexv, unsigned int nr_futexif(*awakened>=0)return1;-if(__get_user(uval,uaddr))+if(futex_get_user(&uval,uaddr,object_size,false))return-EFAULT;retry=true;
@@ -656,9 +701,6 @@ static long ksys_futex_wait(void __user *uaddr, u64 val, unsigned int flags,if(flags&~FUTEX2_MASK)return-EINVAL;-if(size!=FUTEX_32)-return-EINVAL;-futexv=&wait_single.futexv;futexv->task=current;futexv->hint=false;
@@ -667,12 +709,13 @@ static long ksys_futex_wait(void __user *uaddr, u64 val, unsigned int flags,waiter->index=0;waiter->val=val;waiter->uaddr=uaddr;+waiter->flags=flags;memset(&wait_single.waiter.key,0,sizeof(structfutex_key));INIT_LIST_HEAD(&waiter->list);/* Get an unlocked hash bucket */-waiter->bucket=futex_get_bucket(uaddr,&waiter->key,shared);+waiter->bucket=futex_get_bucket(uaddr,&waiter->key,shared,size);if(IS_ERR(waiter->bucket))returnPTR_ERR(waiter->bucket);
@@ -728,8 +771,7 @@ static int compat_futex_parse_waitv(struct futex_waiter_head *futexv,if(copy_from_user(&waitv,&uwaitv[i],sizeof(waitv)))return-EFAULT;-if((waitv.flags&~FUTEXV_WAITER_MASK)||-(waitv.flags&FUTEX_SIZE_MASK)!=FUTEX_32)+if(waitv.flags&~FUTEXV_WAITER_MASK)return-EINVAL;futexv->objects[i].key.pointer=0;
@@ -740,7 +782,7 @@ static int compat_futex_parse_waitv(struct futex_waiter_head *futexv,bucket=futex_get_bucket(compat_ptr(waitv.uaddr),&futexv->objects[i].key,-is_object_shared);+is_object_shared,object_size);if(IS_ERR(bucket))returnPTR_ERR(bucket);
@@ -805,8 +847,7 @@ static int futex_parse_waitv(struct futex_waiter_head *futexv,if(copy_from_user(&waitv,&uwaitv[i],sizeof(waitv)))return-EFAULT;-if((waitv.flags&~FUTEXV_WAITER_MASK)||-(waitv.flags&FUTEX_SIZE_MASK)!=FUTEX_32)+if(waitv.flags&~FUTEXV_WAITER_MASK)return-EINVAL;futexv->objects[i].key.pointer=0;
@@ -816,7 +857,7 @@ static int futex_parse_waitv(struct futex_waiter_head *futexv,futexv->objects[i].index=i;bucket=futex_get_bucket(waitv.uaddr,&futexv->objects[i].key,-is_object_shared);+is_object_shared,object_size);if(IS_ERR(bucket))returnPTR_ERR(bucket);
Implement support for 8, 16 and 64 bit futexes, along with the existing
32 bit support. Userspace should use flags to specify in the syscall
the size of the *uaddr they are operating on.
Variable sized futexes are useful for implementing atomic primitives in
userspace in an efficient manner. 64bit sized futexes are also
particularly useful when userspace stores information to be used in an
atomic fashion on the futex value, given more room for flexibility.
Note that at least in the past, Linus has been vehemently against 64-bit
futexes.
Basically this additional data, like for implementing read/write locks,
does not need to be in the futex atomic wait/wake parts. You can instead
split the userspace lock into two adjacent 32-bit words and do 64-bit
atomic ops on it.
Of course, this is a new interface altogether, so this time it might
be fair game.
Thanks,
Davidlohr
quoted hunk
Overlapping futexes are not allowed, so userspace can't wait and wake on
the same memory address if the are using different sizes.
Signed-off-by: André Almeida <redacted>
---
include/uapi/linux/futex.h | 3 +
kernel/futex2.c | 124 ++++++++++++++++++++++++-------------
2 files changed, 84 insertions(+), 43 deletions(-)
#define FUTEXV_WAITER_MASK (FUTEX_SIZE_MASK | FUTEX_SHARED_FLAG)
#define is_object_shared ((futexv->objects[i].flags & FUTEX_SHARED_FLAG) ? true : false)
+#define object_size (futexv->objects[i].flags & FUTEX_SIZE_MASK)
-#define FUT_OFF_INODE 1 /* We set bit 0 if key has a reference on inode */
-#define FUT_OFF_MMSHARED 2 /* We set bit 1 if key has a reference on mm */
+#define FUT_OFF_INODE PAGE_SIZE
+#define FUT_OFF_MMSHARED (PAGE_SIZE << 1)
+#define FUT_OFF_SIZE 1
static struct futex_bucket *futex_table;
static unsigned int futex2_hashsize;
@@ -321,6 +323,7 @@ static int futex_get_shared_key(uintptr_t address, struct mm_struct *mm, * @uaddr: futex user address * @key: data that uniquely identifies a futex * @shared: is this a shared futex?+ * @flags: flags for the size * * For private futexes, each uaddr will be unique for a given mm_struct, and it * won't be freed for the life time of the process. For shared futexes, check
/**
* futex_get_user - Get the userspace value on this address
- * @uval: variable to store the value
- * @uaddr: userspace address
+ * @uval: variable to store the value
+ * @uaddr: userspace address
+ * @pagefault: true if pagefault should be disabled
+ * @flags: flags for the size
*
* Check the comment at futex_enqueue() for more information.
*/
-static int futex_get_user(u32 *uval, u32 __user *uaddr)
+static int futex_get_user(u64 *uval, void __user *uaddr, unsigned int flags, bool pagefault)
{
int ret;
- pagefault_disable();
- ret = __get_user(*uval, uaddr);
- pagefault_enable();
+ if (pagefault)
+ pagefault_disable();
+
+ switch (flags) {
+ case FUTEX_8:
+ ret = __get_user(*uval, (u8 __user *)uaddr);
+ break;
+ case FUTEX_16:
+ ret = __get_user(*uval, (u16 __user *)uaddr);
+ break;
+ case FUTEX_32:
+ ret = __get_user(*uval, (u32 __user *)uaddr);
+ break;
+ case FUTEX_64:
+ ret = __get_user(*uval, (u64 __user *)uaddr);
+ break;
+ default:
+ BUG();
+ }
+
+ if (pagefault)
+ pagefault_enable();
return ret;
}
@@ -484,8 +528,8 @@ static int futex_enqueue(struct futex_waiter_head *futexv, unsigned int nr_futex
int *awakened)
{
int i, ret;
- u32 uval, val;
- u32 __user *uaddr;
+ u64 uval, val;
+ void __user *uaddr;
bool retry = false;
struct futex_bucket *bucket;
@@ -493,13 +537,14 @@ static int futex_enqueue(struct futex_waiter_head *futexv, unsigned int nr_futex
set_current_state(TASK_INTERRUPTIBLE);
for (i = 0; i < nr_futexes; i++) {
- uaddr = (u32 __user *)futexv->objects[i].uaddr;
- val = (u32)futexv->objects[i].val;
+ uaddr = futexv->objects[i].uaddr;
+ val = (u64)futexv->objects[i].val;
if (is_object_shared && retry) {
struct futex_bucket *tmp =
futex_get_bucket((void __user *)uaddr,
- &futexv->objects[i].key, true);
+ &futexv->objects[i].key, true,
+ object_size);
if (IS_ERR(tmp)) {
__set_current_state(TASK_RUNNING);
futex_dequeue_multiple(futexv, i);
@@ -513,7 +558,7 @@ static int futex_enqueue(struct futex_waiter_head *futexv, unsigned int nr_futex
bucket_inc_waiters(bucket);
spin_lock(&bucket->lock);
- ret = futex_get_user(&uval, uaddr);
+ ret = futex_get_user(&uval, uaddr, object_size, true);
if (unlikely(ret)) {
spin_unlock(&bucket->lock);
@@ -525,7 +570,7 @@ static int futex_enqueue(struct futex_waiter_head *futexv, unsigned int nr_futex
if (*awakened >= 0)
return 1;
- if (__get_user(uval, uaddr))
+ if (futex_get_user(&uval, uaddr, object_size, false))
return -EFAULT;
retry = true;
@@ -656,9 +701,6 @@ static long ksys_futex_wait(void __user *uaddr, u64 val, unsigned int flags,
Implement support for 8, 16 and 64 bit futexes, along with the existing
32 bit support. Userspace should use flags to specify in the syscall
the size of the *uaddr they are operating on.
Variable sized futexes are useful for implementing atomic primitives in
userspace in an efficient manner. 64bit sized futexes are also
particularly useful when userspace stores information to be used in an
atomic fashion on the futex value, given more room for flexibility.
Note that at least in the past, Linus has been vehemently against 64-bit
futexes.
Basically this additional data, like for implementing read/write locks,
does not need to be in the futex atomic wait/wake parts. You can instead
split the userspace lock into two adjacent 32-bit words and do 64-bit
atomic ops on it.
If the kernel performs a 32-bit atomic operation on the futex and the
userspace operates on it using 64-bit atomics, I think you are losing
the atomicity guarantee. For example, Intel SDM Volume 3 Section 8.1.2.2
reads:
Software should access semaphores (shared memory used for signalling
between multiple processors) using identical addresses and operand
lengths. For example, if one processor accesses a semaphore using a
word access, other processors should not access the semaphore using a
byte access.
I wouldn't be surprised if other architectures had a similar requirement.
Of course, this is a new interface altogether, so this time it might
be fair game.
Thanks,
Davidlohr
quoted
Overlapping futexes are not allowed, so userspace can't wait and wake on
the same memory address if the are using different sizes.
Signed-off-by: André Almeida <redacted>
---
include/uapi/linux/futex.h | 3 +
kernel/futex2.c | 124 ++++++++++++++++++++++++-------------
2 files changed, 84 insertions(+), 43 deletions(-)
#define FUTEXV_WAITER_MASK (FUTEX_SIZE_MASK | FUTEX_SHARED_FLAG)
#define is_object_shared ((futexv->objects[i].flags &
FUTEX_SHARED_FLAG) ? true : false)
+#define object_size (futexv->objects[i].flags & FUTEX_SIZE_MASK)
-#define FUT_OFF_INODE 1 /* We set bit 0 if key has a reference on
inode */
-#define FUT_OFF_MMSHARED 2 /* We set bit 1 if key has a reference on
mm */
+#define FUT_OFF_INODE PAGE_SIZE
+#define FUT_OFF_MMSHARED (PAGE_SIZE << 1)
+#define FUT_OFF_SIZE 1
static struct futex_bucket *futex_table;
static unsigned int futex2_hashsize;
@@ -321,6 +323,7 @@ static int futex_get_shared_key(uintptr_t address,
struct mm_struct *mm,
* @uaddr: futex user address
* @key: data that uniquely identifies a futex
* @shared: is this a shared futex?
+ * @flags: flags for the size
*
* For private futexes, each uaddr will be unique for a given
mm_struct, and it
* won't be freed for the life time of the process. For shared
futexes, check
@@ -330,21 +333,41 @@ static int futex_get_shared_key(uintptr_t
*futex_get_bucket(void __user *uaddr,
/**
* futex_get_user - Get the userspace value on this address
- * @uval: variable to store the value
- * @uaddr: userspace address
+ * @uval: variable to store the value
+ * @uaddr: userspace address
+ * @pagefault: true if pagefault should be disabled
+ * @flags: flags for the size
*
* Check the comment at futex_enqueue() for more information.
*/
-static int futex_get_user(u32 *uval, u32 __user *uaddr)
+static int futex_get_user(u64 *uval, void __user *uaddr, unsigned int
flags, bool pagefault)
{
int ret;
- pagefault_disable();
- ret = __get_user(*uval, uaddr);
- pagefault_enable();
+ if (pagefault)
+ pagefault_disable();
+
+ switch (flags) {
+ case FUTEX_8:
+ ret = __get_user(*uval, (u8 __user *)uaddr);
+ break;
+ case FUTEX_16:
+ ret = __get_user(*uval, (u16 __user *)uaddr);
+ break;
+ case FUTEX_32:
+ ret = __get_user(*uval, (u32 __user *)uaddr);
+ break;
+ case FUTEX_64:
+ ret = __get_user(*uval, (u64 __user *)uaddr);
+ break;
+ default:
+ BUG();
+ }
+
+ if (pagefault)
+ pagefault_enable();
return ret;
}
@@ -484,8 +528,8 @@ static int futex_enqueue(struct futex_waiter_head
*futexv, unsigned int nr_futex
int *awakened)
{
int i, ret;
- u32 uval, val;
- u32 __user *uaddr;
+ u64 uval, val;
+ void __user *uaddr;
bool retry = false;
struct futex_bucket *bucket;
@@ -493,13 +537,14 @@ static int futex_enqueue(struct
futex_waiter_head *futexv, unsigned int nr_futex
set_current_state(TASK_INTERRUPTIBLE);
for (i = 0; i < nr_futexes; i++) {
- uaddr = (u32 __user *)futexv->objects[i].uaddr;
- val = (u32)futexv->objects[i].val;
+ uaddr = futexv->objects[i].uaddr;
+ val = (u64)futexv->objects[i].val;
if (is_object_shared && retry) {
struct futex_bucket *tmp =
futex_get_bucket((void __user *)uaddr,
- &futexv->objects[i].key, true);
+ &futexv->objects[i].key, true,
+ object_size);
if (IS_ERR(tmp)) {
__set_current_state(TASK_RUNNING);
futex_dequeue_multiple(futexv, i);
@@ -513,7 +558,7 @@ static int futex_enqueue(struct futex_waiter_head
*futexv, unsigned int nr_futex
bucket_inc_waiters(bucket);
spin_lock(&bucket->lock);
- ret = futex_get_user(&uval, uaddr);
+ ret = futex_get_user(&uval, uaddr, object_size, true);
if (unlikely(ret)) {
spin_unlock(&bucket->lock);
@@ -525,7 +570,7 @@ static int futex_enqueue(struct futex_waiter_head
*futexv, unsigned int nr_futex
if (*awakened >= 0)
return 1;
- if (__get_user(uval, uaddr))
+ if (futex_get_user(&uval, uaddr, object_size, false))
return -EFAULT;
retry = true;
@@ -656,9 +701,6 @@ static long ksys_futex_wait(void __user *uaddr,
u64 val, unsigned int flags,
if (flags & ~FUTEX2_MASK)
return -EINVAL;
- if (size != FUTEX_32)
- return -EINVAL;
-
futexv = &wait_single.futexv;
futexv->task = current;
futexv->hint = false;
@@ -667,12 +709,13 @@ static long ksys_futex_wait(void __user *uaddr,
From: André Almeida <hidden> Date: 2021-06-03 20:00:54
New syscalls should use the same entry point for x86_64 and x86_x32
paths. Add a wrapper for x32 calls to use parse functions that assumes
32bit pointers.
Signed-off-by: André Almeida <redacted>
---
kernel/futex2.c | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
@@ -0,0 +1,198 @@+.. SPDX-License-Identifier: GPL-2.0++======+futex2+======++:Author: André Almeida <andrealmeid@collabora.com>++futex, or fast user mutex, is a set of syscalls to allow userspace to create+performant synchronization mechanisms, such as mutexes, semaphores and+conditional variables in userspace. C standard libraries, like glibc, uses it+as a means to implement more high level interfaces like pthreads.++The interface+=============++uAPI functions+--------------++..kernel-doc:: kernel/futex2.c+:identifiers: sys_futex_wait sys_futex_wake sys_futex_waitv sys_futex_requeue++uAPI structures+---------------++..kernel-doc:: include/uapi/linux/futex.h++The ``flag`` argument+---------------------++The flag is used to specify the size of the futex word+(FUTEX_[8, 16, 32, 64]). It's mandatory to define one, since there's no+default size.++By default, the timeout uses a monotonic clock, but can be used as a realtime+one by using the FUTEX_REALTIME_CLOCK flag.++By default, futexes are of the private type, that means that this user address+will be accessed by threads that share the same memory region. This allows for+some internal optimizations, so they are faster. However, if the address needs+to be shared with different processes (like using ``mmap()`` or ``shm()``), they+need to be defined as shared and the flag FUTEX_SHARED_FLAG is used to set that.++By default, the operation has no NUMA-awareness, meaning that the user can't+choose the memory node where the kernel side futex data will be stored. The+user can choose the node where it wants to operate by setting the+FUTEX_NUMA_FLAG and using the following structure (where X can be 8, 16, 32 or+64)::++ struct futexX_numa {+ __uX value;+ __sX hint;+ };++This structure should be passed at the ``void *uaddr`` of futex functions. The+address of the structure will be used to be waited on/waken on, and the+``value`` will be compared to ``val`` as usual. The ``hint`` member is used to+define which node the futex will use. When waiting, the futex will be+registered on a kernel-side table stored on that node; when waking, the futex+will be searched for on that given table. That means that there's no redundancy+between tables, and the wrong ``hint`` value will lead to undesired behavior.+Userspace is responsible for dealing with node migrations issues that may+occur. ``hint`` can range from [0, MAX_NUMA_NODES), for specifying a node, or+-1, to use the same node the current process is using.++When not using FUTEX_NUMA_FLAG on a NUMA system, the futex will be stored on a+global table on allocated on the first node.++The ``timo`` argument+---------------------++As per the Y2038 work done in the kernel, new interfaces shouldn't add timeout+options known to be buggy. Given that, ``timo`` should be a 64-bit timeout at+all platforms, using an absolute timeout value.++Implementation+==============++The internal implementation follows a similar design to the original futex.+Given that we want to replicate the same external behavior of current futex,+this should be somewhat expected.++Waiting+-------++For the wait operations, they are all treated as if you want to wait on N+futexes, so the path for futex_wait and futex_waitv is the basically the same.+For both syscalls, the first step is to prepare an internal list for the list+of futexes to wait for (using struct futexv_head). For futex_wait() calls, this+list will have a single object.++We have a hash table, where waiters register themselves before sleeping. Then+the wake function checks this table looking for waiters at uaddr. The hash+bucket to be used is determined by a struct futex_key, that stores information+to uniquely identify an address from a given process. Given the huge address+space, there'll be hash collisions, so we store information to be later used on+collision treatment.++First, for every futex we want to wait on, we check if (``*uaddr == val``).+This check is done holding the bucket lock, so we are correctly serialized with+any futex_wake() calls. If any waiter fails the check above, we dequeue all+futexes. The check (``*uaddr == val``) can fail for two reasons:++- The values are different, and we return -EAGAIN. However, if while+ dequeueing we found that some futexes were awakened, we prioritize this+ and return success.++- When trying to access the user address, we do so with page faults+ disabled because we are holding a bucket's spin lock (and can't sleep+ while holding a spin lock). If there's an error, it might be a page+ fault, or an invalid address. We release the lock, dequeue everyone+ (because it's illegal to sleep while there are futexes enqueued, we+ could lose wakeups) and try again with page fault enabled. If we+ succeed, this means that the address is valid, but we need to do+ all the work again. For serialization reasons, we need to have the+ spin lock when getting the user value. Additionally, for shared+ futexes, we also need to recalculate the hash, since the underlying+ mapping mechanisms could have changed when dealing with page fault.+ If, even with page fault enabled, we can't access the address, it+ means it's an invalid user address, and we return -EFAULT. For this+ case, we prioritize the error, even if some futexes were awaken.++If the check is OK, they are enqueued on a linked list in our bucket, and+proceed to the next one. If all waiters succeed, we put the thread to sleep+until a futex_wake() call, timeout expires or we get a signal. After waking up,+we dequeue everyone, and check if some futex was awakened. This dequeue is done+by iteratively walking at each element of struct futex_head list.++All enqueuing/dequeuing operations requires to hold the bucket lock, to avoid+racing while modifying the list.++Waking+------++We get the bucket that's storing the waiters at uaddr, and wake the required+number of waiters, checking for hash collision.++There's an optimization that makes futex_wake() not take the bucket lock if+there's no one to be woken on that bucket. It checks an atomic counter that each+bucket has, if it says 0, then the syscall exits. In order for this to work, the+waiter thread increases it before taking the lock, so the wake thread will+correctly see that there's someone waiting and will continue the path to take+the bucket lock. To get the correct serialization, the waiter issues a memory+barrier after increasing the bucket counter and the waker issues a memory+barrier before checking it.++Requeuing+---------++The requeue path first checks for each struct futex_requeue and their flags.+Then, it will compare the expected value with the one at uaddr1::uaddr.+Following the same serialization explained at Waking_, we increase the atomic+counter for the bucket of uaddr2 before taking the lock. We need to have both+buckets locks at same time so we don't race with other futex operation. To+ensure the locks are taken in the same order for all threads (and thus avoiding+deadlocks), every requeue operation takes the "smaller" bucket first, when+comparing both addresses.++If the compare with user value succeeds, we proceed by waking ``nr_wake``+futexes, and then requeuing ``nr_requeue`` from bucket of uaddr1 to the uaddr2.+This consists in a simple list deletion/addition and replacing the old futex key+with the new one.++Futex keys+----------++There are two types of futexes: private and shared ones. The private are futexes+meant to be used by threads that share the same memory space, are easier to be+uniquely identified and thus can have some performance optimization. The+elements for identifying one are: the start address of the page where the+address is, the address offset within the page and the current->mm pointer.++Now, for uniquely identifying a shared futex:++- If the page containing the user address is an anonymous page, we can+ just use the same data used for private futexes (the start address of+ the page, the address offset within the page and the current->mm+ pointer); that will be enough for uniquely identifying such futex. We+ also set one bit at the key to differentiate if a private futex is+ used on the same address (mixing shared and private calls does not+ work).++- If the page is file-backed, current->mm maybe isn't the same one for+ every user of this futex, so we need to use other data: the+ page->index, a UUID for the struct inode and the offset within the+ page.++Note that members of futex_key don't have any particular meaning after they+are part of the struct - they are just bytes to identify a futex. Given that,+we don't need to use a particular name or type that matches the original data,+we only need to care about the bitsize of each component and make both private+and shared fit in the same memory space.++Source code documentation+=========================++..kernel-doc:: kernel/futex2.c+:no-identifiers: sys_futex_wait sys_futex_wake sys_futex_waitv sys_futex_requeue
Add a new documentation file specifying both userspace API and internal
implementation details of futex2 syscalls.
I think equally important would be to provide a manpage for each new
syscall you are introducing, and keep mkt in the loop as in the past he
extensively documented and improved futex manpages, and overall has a
lot of experience with dealing with kernel interfaces.
Thanks,
Davidlohr
@@ -0,0 +1,198 @@+.. SPDX-License-Identifier: GPL-2.0++======+futex2+======++:Author: André Almeida <andrealmeid@collabora.com>++futex, or fast user mutex, is a set of syscalls to allow userspace to create+performant synchronization mechanisms, such as mutexes, semaphores and+conditional variables in userspace. C standard libraries, like glibc, uses it+as a means to implement more high level interfaces like pthreads.++The interface+=============++uAPI functions+--------------++..kernel-doc:: kernel/futex2.c+:identifiers: sys_futex_wait sys_futex_wake sys_futex_waitv sys_futex_requeue++uAPI structures+---------------++..kernel-doc:: include/uapi/linux/futex.h++The ``flag`` argument+---------------------++The flag is used to specify the size of the futex word+(FUTEX_[8, 16, 32, 64]). It's mandatory to define one, since there's no+default size.++By default, the timeout uses a monotonic clock, but can be used as a realtime+one by using the FUTEX_REALTIME_CLOCK flag.++By default, futexes are of the private type, that means that this user address+will be accessed by threads that share the same memory region. This allows for+some internal optimizations, so they are faster. However, if the address needs+to be shared with different processes (like using ``mmap()`` or ``shm()``), they+need to be defined as shared and the flag FUTEX_SHARED_FLAG is used to set that.++By default, the operation has no NUMA-awareness, meaning that the user can't+choose the memory node where the kernel side futex data will be stored. The+user can choose the node where it wants to operate by setting the+FUTEX_NUMA_FLAG and using the following structure (where X can be 8, 16, 32 or+64)::++ struct futexX_numa {+ __uX value;+ __sX hint;+ };++This structure should be passed at the ``void *uaddr`` of futex functions. The+address of the structure will be used to be waited on/waken on, and the+``value`` will be compared to ``val`` as usual. The ``hint`` member is used to+define which node the futex will use. When waiting, the futex will be+registered on a kernel-side table stored on that node; when waking, the futex+will be searched for on that given table. That means that there's no redundancy+between tables, and the wrong ``hint`` value will lead to undesired behavior.+Userspace is responsible for dealing with node migrations issues that may+occur. ``hint`` can range from [0, MAX_NUMA_NODES), for specifying a node, or+-1, to use the same node the current process is using.++When not using FUTEX_NUMA_FLAG on a NUMA system, the futex will be stored on a+global table on allocated on the first node.++The ``timo`` argument+---------------------++As per the Y2038 work done in the kernel, new interfaces shouldn't add timeout+options known to be buggy. Given that, ``timo`` should be a 64-bit timeout at+all platforms, using an absolute timeout value.++Implementation+==============++The internal implementation follows a similar design to the original futex.+Given that we want to replicate the same external behavior of current futex,+this should be somewhat expected.++Waiting+-------++For the wait operations, they are all treated as if you want to wait on N+futexes, so the path for futex_wait and futex_waitv is the basically the same.+For both syscalls, the first step is to prepare an internal list for the list+of futexes to wait for (using struct futexv_head). For futex_wait() calls, this+list will have a single object.++We have a hash table, where waiters register themselves before sleeping. Then+the wake function checks this table looking for waiters at uaddr. The hash+bucket to be used is determined by a struct futex_key, that stores information+to uniquely identify an address from a given process. Given the huge address+space, there'll be hash collisions, so we store information to be later used on+collision treatment.++First, for every futex we want to wait on, we check if (``*uaddr == val``).+This check is done holding the bucket lock, so we are correctly serialized with+any futex_wake() calls. If any waiter fails the check above, we dequeue all+futexes. The check (``*uaddr == val``) can fail for two reasons:++- The values are different, and we return -EAGAIN. However, if while+ dequeueing we found that some futexes were awakened, we prioritize this+ and return success.++- When trying to access the user address, we do so with page faults+ disabled because we are holding a bucket's spin lock (and can't sleep+ while holding a spin lock). If there's an error, it might be a page+ fault, or an invalid address. We release the lock, dequeue everyone+ (because it's illegal to sleep while there are futexes enqueued, we+ could lose wakeups) and try again with page fault enabled. If we+ succeed, this means that the address is valid, but we need to do+ all the work again. For serialization reasons, we need to have the+ spin lock when getting the user value. Additionally, for shared+ futexes, we also need to recalculate the hash, since the underlying+ mapping mechanisms could have changed when dealing with page fault.+ If, even with page fault enabled, we can't access the address, it+ means it's an invalid user address, and we return -EFAULT. For this+ case, we prioritize the error, even if some futexes were awaken.++If the check is OK, they are enqueued on a linked list in our bucket, and+proceed to the next one. If all waiters succeed, we put the thread to sleep+until a futex_wake() call, timeout expires or we get a signal. After waking up,+we dequeue everyone, and check if some futex was awakened. This dequeue is done+by iteratively walking at each element of struct futex_head list.++All enqueuing/dequeuing operations requires to hold the bucket lock, to avoid+racing while modifying the list.++Waking+------++We get the bucket that's storing the waiters at uaddr, and wake the required+number of waiters, checking for hash collision.++There's an optimization that makes futex_wake() not take the bucket lock if+there's no one to be woken on that bucket. It checks an atomic counter that each+bucket has, if it says 0, then the syscall exits. In order for this to work, the+waiter thread increases it before taking the lock, so the wake thread will+correctly see that there's someone waiting and will continue the path to take+the bucket lock. To get the correct serialization, the waiter issues a memory+barrier after increasing the bucket counter and the waker issues a memory+barrier before checking it.++Requeuing+---------++The requeue path first checks for each struct futex_requeue and their flags.+Then, it will compare the expected value with the one at uaddr1::uaddr.+Following the same serialization explained at Waking_, we increase the atomic+counter for the bucket of uaddr2 before taking the lock. We need to have both+buckets locks at same time so we don't race with other futex operation. To+ensure the locks are taken in the same order for all threads (and thus avoiding+deadlocks), every requeue operation takes the "smaller" bucket first, when+comparing both addresses.++If the compare with user value succeeds, we proceed by waking ``nr_wake``+futexes, and then requeuing ``nr_requeue`` from bucket of uaddr1 to the uaddr2.+This consists in a simple list deletion/addition and replacing the old futex key+with the new one.++Futex keys+----------++There are two types of futexes: private and shared ones. The private are futexes+meant to be used by threads that share the same memory space, are easier to be+uniquely identified and thus can have some performance optimization. The+elements for identifying one are: the start address of the page where the+address is, the address offset within the page and the current->mm pointer.++Now, for uniquely identifying a shared futex:++- If the page containing the user address is an anonymous page, we can+ just use the same data used for private futexes (the start address of+ the page, the address offset within the page and the current->mm+ pointer); that will be enough for uniquely identifying such futex. We+ also set one bit at the key to differentiate if a private futex is+ used on the same address (mixing shared and private calls does not+ work).++- If the page is file-backed, current->mm maybe isn't the same one for+ every user of this futex, so we need to use other data: the+ page->index, a UUID for the struct inode and the offset within the+ page.++Note that members of futex_key don't have any particular meaning after they+are part of the struct - they are just bytes to identify a futex. Given that,+we don't need to use a particular name or type that matches the original data,+we only need to care about the bitsize of each component and make both private+and shared fit in the same memory space.++Source code documentation+=========================++..kernel-doc:: kernel/futex2.c+:no-identifiers: sys_futex_wait sys_futex_wake sys_futex_waitv sys_futex_requeue
From: André Almeida <hidden> Date: 2021-06-03 20:01:06
Add a simple file to test wake/wait mechanism using futex2 interface.
Test three scenarios: using a common local int variable as private
futex, a shm futex as shared futex and a file-backed shared memory as a
shared futex. This should test all branches of futex_get_key().
Create helper files so more tests can evaluate futex2. While 32bit ABIs
from glibc aren't yet able to use 64 bit sized time variables, add a
temporary workaround that implements the required types and calls the
appropriated syscalls, since futex2 doesn't supports 32 bit sized time.
Signed-off-by: André Almeida <redacted>
---
.../selftests/futex/functional/.gitignore | 1 +
.../selftests/futex/functional/Makefile | 4 +-
.../selftests/futex/functional/futex2_wait.c | 195 ++++++++++++++++++
.../testing/selftests/futex/functional/run.sh | 3 +
.../selftests/futex/include/futex2test.h | 79 +++++++
5 files changed, 281 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/futex/functional/futex2_wait.c
create mode 100644 tools/testing/selftests/futex/include/futex2test.h
From: André Almeida <hidden> Date: 2021-06-03 20:01:15
Adapt existing futex wait timeout file to test the same mechanism for
futex2. futex2 accepts only absolute 64bit timers, but supports both
monotonic and realtime clocks.
Signed-off-by: André Almeida <redacted>
---
.../futex/functional/futex_wait_timeout.c | 58 ++++++++++++++++---
1 file changed, 49 insertions(+), 9 deletions(-)
From: André Almeida <hidden> Date: 2021-06-03 20:01:19
Adapt existing futex wait wouldblock file to test the same mechanism for
futex2.
Signed-off-by: André Almeida <redacted>
---
.../futex/functional/futex_wait_wouldblock.c | 33 ++++++++++++++++---
1 file changed, 29 insertions(+), 4 deletions(-)
@@ -61,18 +63,41 @@ int main(int argc, char *argv[])}ksft_print_header();-ksft_set_plan(1);+ksft_set_plan(2);ksft_print_msg("%s: Test the unexpected futex value in FUTEX_WAIT\n",basename(argv[0]));info("Calling futex_wait on f1: %u @ %p with val=%u\n",f1,&f1,f1+1);res=futex_wait(&f1,f1+1,&to,FUTEX_PRIVATE_FLAG);if(!res||errno!=EWOULDBLOCK){-fail("futex_wait returned: %d %s\n",+ksft_test_result_fail("futex_wait returned: %d %s\n",res?errno:res,res?strerror(errno):"");ret=RET_FAIL;+}else{+ksft_test_result_pass("futex_wait wouldblock\n");}-print_result(TEST_NAME,ret);+/* setting absolute timeout for futex2 */+if(gettime64(CLOCK_MONOTONIC,&to64))+error("gettime64 failed\n",errno);++to64.tv_nsec+=timeout_ns;++if(to64.tv_nsec>=1000000000){+to64.tv_sec++;+to64.tv_nsec-=1000000000;+}++info("Calling futex2_wait on f1: %u @ %p with val=%u\n",f1,&f1,f1+1);+res=futex2_wait(&f1,f1+1,FUTEX_32,&to64);+if(!res||errno!=EWOULDBLOCK){+ksft_test_result_fail("futex2_wait returned: %d %s\n",+res?errno:res,res?strerror(errno):"");+ret=RET_FAIL;+}else{+ksft_test_result_pass("futex2_wait wouldblock\n");+}++ksft_print_cnts();returnret;}
From: André Almeida <hidden> Date: 2021-06-03 20:01:23
Create a new file to test the waitv mechanism. Test both private and
shared futexes. Wake the last futex in the array, and check if the
return value from futex_waitv() is the right index.
Signed-off-by: André Almeida <redacted>
---
.../selftests/futex/functional/.gitignore | 1 +
.../selftests/futex/functional/Makefile | 3 +-
.../selftests/futex/functional/futex2_waitv.c | 154 ++++++++++++++++++
.../testing/selftests/futex/functional/run.sh | 3 +
.../selftests/futex/include/futex2test.h | 17 ++
5 files changed, 177 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/futex/functional/futex2_waitv.c
From: André Almeida <hidden> Date: 2021-06-03 20:01:30
Add testing for futex_requeue(). The first test just requeue from one
waiter to another one, and wake it. The second performs both wake and
requeue, and we check return values to see if the operation
woke/requeued the expected number of waiters.
Signed-off-by: André Almeida <redacted>
---
.../selftests/futex/functional/.gitignore | 1 +
.../selftests/futex/functional/Makefile | 3 +-
.../futex/functional/futex2_requeue.c | 164 ++++++++++++++++++
.../selftests/futex/include/futex2test.h | 16 ++
4 files changed, 183 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/futex/functional/futex2_requeue.c
From: André Almeida <hidden> Date: 2021-06-03 20:01:34
Add a selftest for the variable size futex2 API. This initial test
just validates the basic (and correct) case, where both uses the same
size and the value is in the correct range.
Signed-off-by: André Almeida <redacted>
---
.../selftests/futex/functional/.gitignore | 1 +
.../selftests/futex/functional/Makefile | 3 +-
.../selftests/futex/functional/futex2_sizes.c | 146 ++++++++++++++++++
.../selftests/futex/include/futex2test.h | 3 +-
4 files changed, 151 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/futex/functional/futex2_sizes.c
From: André Almeida <hidden> Date: 2021-06-03 20:01:40
Add support at the existing futex benchmarking code base to enable
futex2 calls. `perf bench` tests can be used not only as a way to
measure the performance of implementation, but also as stress testing
for the kernel infrastructure.
Signed-off-by: André Almeida <redacted>
---
tools/arch/x86/include/asm/unistd_64.h | 12 ++++++
tools/perf/bench/bench.h | 4 ++
tools/perf/bench/futex-hash.c | 24 +++++++++--
tools/perf/bench/futex-requeue.c | 57 ++++++++++++++++++++------
tools/perf/bench/futex-wake-parallel.c | 41 +++++++++++++++---
tools/perf/bench/futex-wake.c | 37 +++++++++++++----
tools/perf/bench/futex.h | 47 +++++++++++++++++++++
tools/perf/builtin-bench.c | 18 ++++++--
8 files changed, 206 insertions(+), 34 deletions(-)
@@ -111,7 +118,7 @@ static void toggle_done(int sig __maybe_unused,done=true;}-intbench_futex_requeue(intargc,constchar**argv)+staticint__bench_futex_requeue(intargc,constchar**argv){intret=0;unsignedinti,j;
@@ -139,15 +146,20 @@ int bench_futex_requeue(int argc, const char **argv)if(!worker)err(EXIT_FAILURE,"calloc");-if(!fshared)+if(futex2){+futex_flag=FUTEX_32|(fshared*FUTEX_SHARED_FLAG);+rq1.flags|=FUTEX_SHARED_FLAG*fshared;+rq2.flags|=FUTEX_SHARED_FLAG*fshared;+}elseif(!fshared){futex_flag=FUTEX_PRIVATE_FLAG;+}if(nrequeue>nthreads)nrequeue=nthreads;printf("Run summary [PID %d]: Requeuing %d threads (from [%s] %p to %p), ""%d at a time.\n\n",getpid(),nthreads,-fshared?"shared":"private",&futex1,&futex2,nrequeue);+fshared?"shared":"private",&addr1,&addr2,nrequeue);init_stats(&requeued_stats);init_stats(&requeuetime_stats);
@@ -176,11 +188,15 @@ int bench_futex_requeue(int argc, const char **argv)gettimeofday(&start,NULL);while(nrequeued<nthreads){/*-*Donotwakeupanytasksblockedonfutex1,allowing+*Donotwakeupanytasksblockedonaddr1,allowing*ustoreallymeasurefutex_waitfunctionality.*/-nrequeued+=futex_cmp_requeue(&futex1,0,&futex2,0,-nrequeue,futex_flag);+if(!futex2)+nrequeued+=futex_cmp_requeue(&addr1,0,&addr2,+0,nrequeue,futex_flag);+else+nrequeued+=futex2_requeue(&rq1,&rq2,+0,nrequeue,0,0);}gettimeofday(&end,NULL);
@@ -194,8 +210,12 @@ int bench_futex_requeue(int argc, const char **argv)j+1,nrequeued,nthreads,runtime.tv_usec/(double)USEC_PER_MSEC);}-/* everybody should be blocked on futex2, wake'em up */-nrequeued=futex_wake(&futex2,nrequeued,futex_flag);+/* everybody should be blocked on addr2, wake'em up */+if(!futex2)+nrequeued=futex_wake(&addr2,nrequeued,futex_flag);+else+nrequeued=futex2_wake(&addr2,nrequeued,futex_flag);+if(nthreads!=nrequeued)warnx("couldn't wakeup all tasks (%d/%d)",nrequeued,nthreads);
@@ -220,3 +240,14 @@ int bench_futex_requeue(int argc, const char **argv)usage_with_options(bench_futex_requeue_usage,options);exit(EXIT_FAILURE);}++intbench_futex_requeue(intargc,constchar**argv)+{+return__bench_futex_requeue(argc,argv);+}++intbench_futex2_requeue(intargc,constchar**argv)+{+futex2=true;+return__bench_futex_requeue(argc,argv);+}
From: André Almeida <hidden> Date: 2021-06-03 20:01:52
To make pthreads works as expected if they are using futex2, wake
clear_child_tid with futex2 as well. This is make applications that uses
waitpid() (and clone(CLONE_CHILD_SETTID)) wake while waiting for the
child to terminate. Given that apps should not mix futex() and futex2(),
any correct app will trigger a harmless noop wakeup on the interface
that it isn't using.
Signed-off-by: André Almeida <redacted>
---
This commit is here for the intend to show what we need to do in order
to get a full NPTL working on top of futex2. It should be merged after
we talk to glibc folks on the details around the futex_wait() side. For
instance, we could use this as an opportunity to use private futexes or
8bit sized futexes, but both sides need to use the exactly same flags.
---
include/linux/syscalls.h | 2 ++
kernel/fork.c | 2 ++
kernel/futex2.c | 30 ++++++++++++++++++------------
3 files changed, 22 insertions(+), 12 deletions(-)
@@ -1324,6 +1324,8 @@ int ksys_ipc(unsigned int call, int first, unsigned long second,unsignedlongthird,void__user*ptr,longfifth);intcompat_ksys_ipc(u32call,intfirst,intsecond,u32third,u32ptr,u32fifth);+longksys_futex_wake(void__user*uaddr,unsignedlongnr_wake,+unsignedintflags);/**Thefollowingkernelsyscallequivalentsarejustwrapperstofs-internal
From: Zebediah Figura <hidden> Date: 2021-06-04 04:52:55
On 6/3/21 2:59 PM, André Almeida wrote:
** The wait on multiple problem
The use case lies in the Wine implementation of the Windows NT interface
WaitMultipleObjects. This Windows API function allows a thread to sleep
waiting on the first of a set of event sources (mutexes, timers, signal,
console input, etc) to signal. Considering this is a primitive
synchronization operation for Windows applications, being able to quickly
signal events on the producer side, and quickly go to sleep on the
consumer side is essential for good performance of those running over Wine.
I know this is part of the cover letter, but I really do want to clarify
that this isn't really accurate. The use case that this is referring to
is not "the Wine implementation of WaitForMultipleObjects", it is an
out-of-tree implementation of WaitForMultipleObjects that provides
improved performance compared to the in-tree implementation.
This is especially salient because:
(1) this out-of-tree implementation is only in a small handful of cases
any more performant than a different out-of-tree implementation which
uses eventfd and poll() instead;
(2) these implementations will remain out-of-tree due to compatibility
and robustness problems;
(3) I believe there is potential for an upstreamable implementation
which does not rely on futex or futex2.
From: André Almeida <hidden> Date: 2021-06-04 17:04:34
Às 01:51 de 04/06/21, Zebediah Figura escreveu:
On 6/3/21 2:59 PM, André Almeida wrote:
quoted
** The wait on multiple problem
The use case lies in the Wine implementation of the Windows NT
interface
WaitMultipleObjects. This Windows API function allows a thread to sleep
waiting on the first of a set of event sources (mutexes, timers,
signal,
console input, etc) to signal. Considering this is a primitive
synchronization operation for Windows applications, being able to
quickly
signal events on the producer side, and quickly go to sleep on the
consumer side is essential for good performance of those running
over Wine.
I know this is part of the cover letter, but I really do want to clarify
that this isn't really accurate. The use case that this is referring to
is not "the Wine implementation of WaitForMultipleObjects", it is an
out-of-tree implementation of WaitForMultipleObjects that provides
improved performance compared to the in-tree implementation.
This is especially salient because:
(1) this out-of-tree implementation is only in a small handful of cases
any more performant than a different out-of-tree implementation which
uses eventfd and poll() instead;
(2) these implementations will remain out-of-tree due to compatibility
and robustness problems;
(3) I believe there is potential for an upstreamable implementation
which does not rely on futex or futex2.
I'll let it more clear next time that this applies to Proton's Wine, and
not Wine.
Along with that, wait on multiple will be useful for other workloads,
such as the ones that uses Boost's mass locking algorithms and native
game engines for instance.
From: Nicholas Piggin <npiggin@gmail.com> Date: 2021-06-04 11:38:00
Excerpts from André Almeida's message of June 4, 2021 5:59 am:
Hi,
This patch series introduces the futex2 syscalls.
* What happened to the current futex()?
For some years now, developers have been trying to add new features to
futex, but maintainers have been reluctant to accept then, given the
multiplexed interface full of legacy features and tricky to do big
changes. Some problems that people tried to address with patchsets are:
NUMA-awareness[0], smaller sized futexes[1], wait on multiple futexes[2].
NUMA, for instance, just doesn't fit the current API in a reasonable
way. Considering that, it's not possible to merge new features into the
current futex.
** The NUMA problem
At the current implementation, all futex kernel side infrastructure is
stored on a single node. Given that, all futex() calls issued by
processors that aren't located on that node will have a memory access
penalty when doing it.
** The 32bit sized futex problem
Futexes are used to implement atomic operations in userspace.
Supporting 8, 16, 32 and 64 bit sized futexes allows user libraries to
implement all those sizes in a performant way. Thanks Boost devs for
feedback: https://lists.boost.org/Archives/boost/2021/05/251508.php
Embedded systems or anything with memory constrains could benefit of
using smaller sizes for the futex userspace integer.
** The wait on multiple problem
The use case lies in the Wine implementation of the Windows NT interface
WaitMultipleObjects. This Windows API function allows a thread to sleep
waiting on the first of a set of event sources (mutexes, timers, signal,
console input, etc) to signal. Considering this is a primitive
synchronization operation for Windows applications, being able to quickly
signal events on the producer side, and quickly go to sleep on the
consumer side is essential for good performance of those running over Wine.
[0] https://lore.kernel.org/lkml/20160505204230.932454245@linutronix.de/
[1] https://lore.kernel.org/lkml/20191221155659.3159-2-malteskarupke@web.de/
[2] https://lore.kernel.org/lkml/20200213214525.183689-1-andrealmeid@collabora.com/
* The solution
As proposed by Peter Zijlstra and Florian Weimer[3], a new interface
is required to solve this, which must be designed with those features in
mind. futex2() is that interface. As opposed to the current multiplexed
interface, the new one should have one syscall per operation. This will
allow the maintainability of the API if it gets extended, and will help
users with type checking of arguments.
In particular, the new interface is extended to support the ability to
wait on any of a list of futexes at a time, which could be seen as a
vectored extension of the FUTEX_WAIT semantics.
[3] https://lore.kernel.org/lkml/20200303120050.GC2596@hirez.programming.kicks-ass.net/
* The interface
The new interface can be seen in details in the following patches, but
this is a high level summary of what the interface can do:
- Supports wake/wait semantics, as in futex()
- Supports requeue operations, similarly as FUTEX_CMP_REQUEUE, but with
individual flags for each address
- Supports waiting for a vector of futexes, using a new syscall named
futex_waitv()
- Supports variable sized futexes (8bits, 16bits, 32bits and 64bits)
- Supports NUMA-awareness operations, where the user can specify on
which memory node would like to operate
A few comments.
- Do you need a syscall for wait and for waitv, or can wait just be a
degenerate case of waitv (which could use the stack variable)? I guess
it does save the user access unlock.
- Did you consider a wakev interface? An example is a read-write mutex
which has read-blocking futexes split (e.g., per-node) for scalability
then the writer may unlock and wake all readers with one call. We
actually have some scalability challenges of this nature with certain
large database programs.
- Great to see 64-bit support in, it is helpful to do some interesting
things with locks without hacks (e.g., putting an address in the lock
word).
- Are we really keen on squashing node ID into flags in this day and age?
I guess okay but seems like it would be nice to allow a bit more space
in general for the operations. I don't want to turn it into a whole big
multiplexing nightmare again with lots of such flags, or propose
complexity with no code behind it, but I think we need a bit of leeway
for unforeseen locking innovations to be added carefully. The pthread
locking today is still fairly primitive really, I don't think we know
what will work best for the next 10 years.
One scalability issue we are starting to hit and will only get worse is
futex queue spinlock contention. Perhaps this is better addressed in
userspace but the kernel could play a part so I like to leave some doors
open. One example is that the wait (or wake) side may like to depend not
just on the memory value, but on the success of a cmpxchg to avoid
unqueueing and queueing spuriously, which increases lock contention but
also ends up putting the poor task on the back of the list -- yes RT
priorities can help the realtime case, but non-RT cases can get bad
outlier latencies if lock stealing is allowed (which can be very good
for performance).
- The private global futex hash table sucks for various reasons, and
having 128 waiters per thread makes it orders of magnitude easier for
userspace to DoS stuff with hash collisions. NUMA doesn't fix that, the
per process hashing that Thomas suggested does fix the DoS but the
non-deterministic hash collisions still seem to be a problem for real
time response, and at the other end of the scale some apps (certain
databases, etc) can have ten thousand futex waiters at once so birthday
paradox can also lead to guaranteed (low level) variable beahviour
within a single process.
I know the kernel in general is not very robust against this kind of
DoS/nondeterminism, but it's a bit sad to introduce new APIs with the
problem still there. Yes we could address it later, but I think it's
better done first because the solution might influence what the best
syscall API is.
For example the idea of using the address as the handle for the wait
queue _and_ the value is very convenient but hashing is annoying for
all the above reasons and the shared wait queue case is pretty clunky.
It's also constraining in some corner cases to have the wait queue
associated with the address 1:1. For example a type of NUMA mutex might
want to have per-node waitqueues associated with a lock word, and wake
local node waiters 99% of the time. Not trivial to do with futexes and
seems to at least require bouncing of more cache lines, possibly more
atomics, etc.
Could anything else be done?
I'll be burned at the stake for suggesting it but it would be great if
we could use file descriptors. At least for the shared futex, maybe
private could use a per-process futex allocator. It solves all of the
above, although I'm sure has many of its own problem. It may not play
so nicely with the pthread mutex API because of the whole static
initialiser problem, but the first futex proposal did use fds. But it's
an example of an alternate API.
And.. thanks for the great work, apologies if I missed some discussion
related to the above comments, I did some reading but I know there has
been a lot of discussions going on.
Thanks,
Nick
From: André Almeida <hidden> Date: 2021-06-04 20:01:17
Às 08:36 de 04/06/21, Nicholas Piggin escreveu:
Excerpts from André Almeida's message of June 4, 2021 5:59 am:
quoted
Hi,
This patch series introduces the futex2 syscalls.
* What happened to the current futex()?
For some years now, developers have been trying to add new features to
futex, but maintainers have been reluctant to accept then, given the
multiplexed interface full of legacy features and tricky to do big
changes. Some problems that people tried to address with patchsets are:
NUMA-awareness[0], smaller sized futexes[1], wait on multiple futexes[2].
NUMA, for instance, just doesn't fit the current API in a reasonable
way. Considering that, it's not possible to merge new features into the
current futex.
** The NUMA problem
At the current implementation, all futex kernel side infrastructure is
stored on a single node. Given that, all futex() calls issued by
processors that aren't located on that node will have a memory access
penalty when doing it.
** The 32bit sized futex problem
Futexes are used to implement atomic operations in userspace.
Supporting 8, 16, 32 and 64 bit sized futexes allows user libraries to
implement all those sizes in a performant way. Thanks Boost devs for
feedback: https://lists.boost.org/Archives/boost/2021/05/251508.php
Embedded systems or anything with memory constrains could benefit of
using smaller sizes for the futex userspace integer.
** The wait on multiple problem
The use case lies in the Wine implementation of the Windows NT interface
WaitMultipleObjects. This Windows API function allows a thread to sleep
waiting on the first of a set of event sources (mutexes, timers, signal,
console input, etc) to signal. Considering this is a primitive
synchronization operation for Windows applications, being able to quickly
signal events on the producer side, and quickly go to sleep on the
consumer side is essential for good performance of those running over Wine.
[0] https://lore.kernel.org/lkml/20160505204230.932454245@linutronix.de/
[1] https://lore.kernel.org/lkml/20191221155659.3159-2-malteskarupke@web.de/
[2] https://lore.kernel.org/lkml/20200213214525.183689-1-andrealmeid@collabora.com/
* The solution
As proposed by Peter Zijlstra and Florian Weimer[3], a new interface
is required to solve this, which must be designed with those features in
mind. futex2() is that interface. As opposed to the current multiplexed
interface, the new one should have one syscall per operation. This will
allow the maintainability of the API if it gets extended, and will help
users with type checking of arguments.
In particular, the new interface is extended to support the ability to
wait on any of a list of futexes at a time, which could be seen as a
vectored extension of the FUTEX_WAIT semantics.
[3] https://lore.kernel.org/lkml/20200303120050.GC2596@hirez.programming.kicks-ass.net/
* The interface
The new interface can be seen in details in the following patches, but
this is a high level summary of what the interface can do:
- Supports wake/wait semantics, as in futex()
- Supports requeue operations, similarly as FUTEX_CMP_REQUEUE, but with
individual flags for each address
- Supports waiting for a vector of futexes, using a new syscall named
futex_waitv()
- Supports variable sized futexes (8bits, 16bits, 32bits and 64bits)
- Supports NUMA-awareness operations, where the user can specify on
which memory node would like to operate
A few comments.
- Do you need a syscall for wait and for waitv, or can wait just be a
degenerate case of waitv (which could use the stack variable)? I guess
it does save the user access unlock.
Yes. waitv with one element has a overhead compared to wait, given the
extra user_copy(). Given that waiting on a single futex is the common
case, I think it's worth to have it.
- Did you consider a wakev interface? An example is a read-write mutex
which has read-blocking futexes split (e.g., per-node) for scalability
then the writer may unlock and wake all readers with one call. We
actually have some scalability challenges of this nature with certain
large database programs.
Not really, I haven't heard any use case for that until now. It should
be easy to implement it, though, and I think you have an interesting use
case here. Could you point me some of those database programs?
- Great to see 64-bit support in, it is helpful to do some interesting
things with locks without hacks (e.g., putting an address in the lock
word).
- Are we really keen on squashing node ID into flags in this day and age?
I guess okay but seems like it would be nice to allow a bit more space
in general for the operations. I don't want to turn it into a whole big
multiplexing nightmare again with lots of such flags, or propose
complexity with no code behind it, but I think we need a bit of leeway
for unforeseen locking innovations to be added carefully. The pthread
locking today is still fairly primitive really, I don't think we know
what will work best for the next 10 years.
In the interface that I'd proposed, the node ID isn't part of the flags.
You have a flag FUTEX_FLAG_NUMA, and when that is used, you pass in
`void *uaddr` a pointer to a `struct futex_numa { int value, int hint
}`, where hint should be the node ID you would like to work on, and
value is just the userspace futex. This is documented in more details in
patch 7 "docs: locking: futex2: Add documentation".
If you have any feedback about how this NUMA interface looks like, I
would like to hear.
Also, did something in my writing indicated that the node ID would be
part of the flags? I'll improve this it if so.
One scalability issue we are starting to hit and will only get worse is
futex queue spinlock contention. Perhaps this is better addressed in
userspace but the kernel could play a part so I like to leave some doors
open. One example is that the wait (or wake) side may like to depend not
just on the memory value, but on the success of a cmpxchg to avoid
unqueueing and queueing spuriously, which increases lock contention but
also ends up putting the poor task on the back of the list -- yes RT
priorities can help the realtime case, but non-RT cases can get bad
outlier latencies if lock stealing is allowed (which can be very good
for performance).
Sorry, I'm not sure what do you mean here. Are you proposing to have a
cmpxchg in kernel side, so the lock would be taken by the kernel, and
not by the userspace like it's now?
- The private global futex hash table sucks for various reasons, and
having 128 waiters per thread makes it orders of magnitude easier for
userspace to DoS stuff with hash collisions. NUMA doesn't fix that, the
per process hashing that Thomas suggested does fix the DoS but the
non-deterministic hash collisions still seem to be a problem for real
time response, and at the other end of the scale some apps (certain
databases, etc) can have ten thousand futex waiters at once so birthday
paradox can also lead to guaranteed (low level) variable beahviour
within a single process.
I know the kernel in general is not very robust against this kind of
DoS/nondeterminism, but it's a bit sad to introduce new APIs with the
problem still there. Yes we could address it later, but I think it's
better done first because the solution might influence what the best
syscall API is.
For example the idea of using the address as the handle for the wait
queue _and_ the value is very convenient but hashing is annoying for
all the above reasons and the shared wait queue case is pretty clunky.
It's also constraining in some corner cases to have the wait queue
associated with the address 1:1. For example a type of NUMA mutex might
want to have per-node waitqueues associated with a lock word, and wake
local node waiters 99% of the time. Not trivial to do with futexes and
seems to at least require bouncing of more cache lines, possibly more
atomics, etc.
Could anything else be done?
I wasn't aware that userspace doing DoS is something to be concerned
from the kernel point of view. Is this scenario considering a malicious
actor? If so, there are plenty of resources to be denied, so not sure
how futex could be protected of this. Or is this just a program that
uses tons of futexes?
I'll be burned at the stake for suggesting it but it would be great if
we could use file descriptors. At least for the shared futex, maybe
private could use a per-process futex allocator. It solves all of the
above, although I'm sure has many of its own problem. It may not play
so nicely with the pthread mutex API because of the whole static
initialiser problem, but the first futex proposal did use fds. But it's
an example of an alternate API.
FDs and futex doesn't play well, because for futex_wait() you need to
tell the kernel the expected value in the futex address to avoid
sleeping in a free lock. FD operations (poll, select) don't have this
`value` argument, so they could sleep forever, but I'm not sure if you
had taken this in consideration.
And.. thanks for the great work, apologies if I missed some discussion
related to the above comments, I did some reading but I know there has
been a lot of discussions going on.
:) and thank you for the valuable feedback and detailed ideas!
From: Nicholas Piggin <npiggin@gmail.com> Date: 2021-06-05 01:10:02
Excerpts from André Almeida's message of June 5, 2021 6:01 am:
Às 08:36 de 04/06/21, Nicholas Piggin escreveu:
quoted
Excerpts from André Almeida's message of June 4, 2021 5:59 am:
quoted
Hi,
This patch series introduces the futex2 syscalls.
* What happened to the current futex()?
For some years now, developers have been trying to add new features to
futex, but maintainers have been reluctant to accept then, given the
multiplexed interface full of legacy features and tricky to do big
changes. Some problems that people tried to address with patchsets are:
NUMA-awareness[0], smaller sized futexes[1], wait on multiple futexes[2].
NUMA, for instance, just doesn't fit the current API in a reasonable
way. Considering that, it's not possible to merge new features into the
current futex.
** The NUMA problem
At the current implementation, all futex kernel side infrastructure is
stored on a single node. Given that, all futex() calls issued by
processors that aren't located on that node will have a memory access
penalty when doing it.
** The 32bit sized futex problem
Futexes are used to implement atomic operations in userspace.
Supporting 8, 16, 32 and 64 bit sized futexes allows user libraries to
implement all those sizes in a performant way. Thanks Boost devs for
feedback: https://lists.boost.org/Archives/boost/2021/05/251508.php
Embedded systems or anything with memory constrains could benefit of
using smaller sizes for the futex userspace integer.
** The wait on multiple problem
The use case lies in the Wine implementation of the Windows NT interface
WaitMultipleObjects. This Windows API function allows a thread to sleep
waiting on the first of a set of event sources (mutexes, timers, signal,
console input, etc) to signal. Considering this is a primitive
synchronization operation for Windows applications, being able to quickly
signal events on the producer side, and quickly go to sleep on the
consumer side is essential for good performance of those running over Wine.
[0] https://lore.kernel.org/lkml/20160505204230.932454245@linutronix.de/
[1] https://lore.kernel.org/lkml/20191221155659.3159-2-malteskarupke@web.de/
[2] https://lore.kernel.org/lkml/20200213214525.183689-1-andrealmeid@collabora.com/
* The solution
As proposed by Peter Zijlstra and Florian Weimer[3], a new interface
is required to solve this, which must be designed with those features in
mind. futex2() is that interface. As opposed to the current multiplexed
interface, the new one should have one syscall per operation. This will
allow the maintainability of the API if it gets extended, and will help
users with type checking of arguments.
In particular, the new interface is extended to support the ability to
wait on any of a list of futexes at a time, which could be seen as a
vectored extension of the FUTEX_WAIT semantics.
[3] https://lore.kernel.org/lkml/20200303120050.GC2596@hirez.programming.kicks-ass.net/
* The interface
The new interface can be seen in details in the following patches, but
this is a high level summary of what the interface can do:
- Supports wake/wait semantics, as in futex()
- Supports requeue operations, similarly as FUTEX_CMP_REQUEUE, but with
individual flags for each address
- Supports waiting for a vector of futexes, using a new syscall named
futex_waitv()
- Supports variable sized futexes (8bits, 16bits, 32bits and 64bits)
- Supports NUMA-awareness operations, where the user can specify on
which memory node would like to operate
A few comments.
- Do you need a syscall for wait and for waitv, or can wait just be a
degenerate case of waitv (which could use the stack variable)? I guess
it does save the user access unlock.
Yes. waitv with one element has a overhead compared to wait, given the
extra user_copy(). Given that waiting on a single futex is the common
case, I think it's worth to have it.
Okay.
quoted
- Did you consider a wakev interface? An example is a read-write mutex
which has read-blocking futexes split (e.g., per-node) for scalability
then the writer may unlock and wake all readers with one call. We
actually have some scalability challenges of this nature with certain
large database programs.
Not really, I haven't heard any use case for that until now. It should
be easy to implement it, though, and I think you have an interesting use
case here. Could you point me some of those database programs?
Not source code unfortunately. I know that's not a very good answer, but
they are far ahead of what most open source apps are doing scalability
wise today, and they end up rolling their own complex locking. Hopefully
the example I give is simple enough to understand.
quoted
- Great to see 64-bit support in, it is helpful to do some interesting
things with locks without hacks (e.g., putting an address in the lock
word).
- Are we really keen on squashing node ID into flags in this day and age?
I guess okay but seems like it would be nice to allow a bit more space
in general for the operations. I don't want to turn it into a whole big
multiplexing nightmare again with lots of such flags, or propose
complexity with no code behind it, but I think we need a bit of leeway
for unforeseen locking innovations to be added carefully. The pthread
locking today is still fairly primitive really, I don't think we know
what will work best for the next 10 years.
In the interface that I'd proposed, the node ID isn't part of the flags.
You have a flag FUTEX_FLAG_NUMA, and when that is used, you pass in
`void *uaddr` a pointer to a `struct futex_numa { int value, int hint
}`, where hint should be the node ID you would like to work on, and
value is just the userspace futex. This is documented in more details in
patch 7 "docs: locking: futex2: Add documentation".
If you have any feedback about how this NUMA interface looks like, I
would like to hear.
Also, did something in my writing indicated that the node ID would be
part of the flags? I'll improve this it if so.
Oh I did miss this, thank you. No it wasn't your writing, I think it was
me trying to read through a lot of messages and got confused with some
earlier conversations.
I'll look a bit more at the NUMA interface.
quoted
One scalability issue we are starting to hit and will only get worse is
futex queue spinlock contention. Perhaps this is better addressed in
userspace but the kernel could play a part so I like to leave some doors
open. One example is that the wait (or wake) side may like to depend not
just on the memory value, but on the success of a cmpxchg to avoid
unqueueing and queueing spuriously, which increases lock contention but
also ends up putting the poor task on the back of the list -- yes RT
priorities can help the realtime case, but non-RT cases can get bad
outlier latencies if lock stealing is allowed (which can be very good
for performance).
Sorry, I'm not sure what do you mean here. Are you proposing to have a
cmpxchg in kernel side, so the lock would be taken by the kernel, and
not by the userspace like it's now?
Yes. Only in slow paths, of course, to reduce starvation / erratic
latencies and spurious wait queue manipulations.
Actually one other scalability thing while I remember it:
futex_wait currently requires that the lock word is tested under the
queue spin lock (to avoid consuming a wakeup). The problem with this is
that the lock word can be a very hot cache line if you have a lot of
concurrency, so accessing it under the queue lock can increase queue
lock hold time.
I would prefer if the new API was relaxed to avoid this restriction
(e.g., any wait call may consume a wakeup so it's up to userspace to
avoid that if it is a problem).
quoted
- The private global futex hash table sucks for various reasons, and
having 128 waiters per thread makes it orders of magnitude easier for
userspace to DoS stuff with hash collisions. NUMA doesn't fix that, the
per process hashing that Thomas suggested does fix the DoS but the
non-deterministic hash collisions still seem to be a problem for real
time response, and at the other end of the scale some apps (certain
databases, etc) can have ten thousand futex waiters at once so birthday
paradox can also lead to guaranteed (low level) variable beahviour
within a single process.
I know the kernel in general is not very robust against this kind of
DoS/nondeterminism, but it's a bit sad to introduce new APIs with the
problem still there. Yes we could address it later, but I think it's
better done first because the solution might influence what the best
syscall API is.
For example the idea of using the address as the handle for the wait
queue _and_ the value is very convenient but hashing is annoying for
all the above reasons and the shared wait queue case is pretty clunky.
It's also constraining in some corner cases to have the wait queue
associated with the address 1:1. For example a type of NUMA mutex might
want to have per-node waitqueues associated with a lock word, and wake
local node waiters 99% of the time. Not trivial to do with futexes and
seems to at least require bouncing of more cache lines, possibly more
atomics, etc.
Could anything else be done?
I wasn't aware that userspace doing DoS is something to be concerned
from the kernel point of view. Is this scenario considering a malicious
actor? If so, there are plenty of resources to be denied, so not sure
how futex could be protected of this. Or is this just a program that
uses tons of futexes?
Both really. AFAIKS one of the efforts that prompted the futex
modernisation work was the RT latency issues from Thomas in 2016 when
the per process table was proposed.
quoted
I'll be burned at the stake for suggesting it but it would be great if
we could use file descriptors. At least for the shared futex, maybe
private could use a per-process futex allocator. It solves all of the
above, although I'm sure has many of its own problem. It may not play
so nicely with the pthread mutex API because of the whole static
initialiser problem, but the first futex proposal did use fds. But it's
an example of an alternate API.
FDs and futex doesn't play well, because for futex_wait() you need to
tell the kernel the expected value in the futex address to avoid
sleeping in a free lock. FD operations (poll, select) don't have this
`value` argument, so they could sleep forever, but I'm not sure if you
had taken this in consideration.
I had. The futex wait API would take a fd additional. The only
difference is the waitqueue that is used when a sleep or wake is
required is derived from the fd, not from an address.
I think the bigger sticking points would be if it's too heavyweight an
object to use (which could be somewhat mitigated with a simpler ida
allocator although that's difficult to do with shared), and whether libc
could sanely use them due to the static initialiser problem of pthread
mutexes.
Thanks,
Nick
Excerpts from André Almeida's message of June 5, 2021 6:01 am:
quoted
Às 08:36 de 04/06/21, Nicholas Piggin escreveu:
quoted
quoted
I'll be burned at the stake for suggesting it but it would be great if
we could use file descriptors. At least for the shared futex, maybe
private could use a per-process futex allocator. It solves all of the
above, although I'm sure has many of its own problem. It may not play
so nicely with the pthread mutex API because of the whole static
initialiser problem, but the first futex proposal did use fds. But it's
an example of an alternate API.
FDs and futex doesn't play well, because for futex_wait() you need to
tell the kernel the expected value in the futex address to avoid
sleeping in a free lock. FD operations (poll, select) don't have this
`value` argument, so they could sleep forever, but I'm not sure if you
had taken this in consideration.
I had. The futex wait API would take a fd additional. The only
difference is the waitqueue that is used when a sleep or wake is
required is derived from the fd, not from an address.
I think the bigger sticking points would be if it's too heavyweight an
object to use (which could be somewhat mitigated with a simpler ida
allocator although that's difficult to do with shared), and whether libc
could sanely use them due to the static initialiser problem of pthread
mutexes.
The static initialization feature is not the only benefit of the current
futex design, and probably not the most important one. You can work
around the static initialization in userspace, e.g. by initializing fd
to an invalid value and creating a valid fd upon the first use. Although
that would still incur a performance penalty and add a new source of
failure.
What is more important is that waiting on fd always requires a kernel
call. This will be terrible for performance of uncontended locks, which
is the majority of time.
Another important point is that a futex that is not being waited on
consumes zero kernel resources while fd is a limited resource even when
not used. You can have millions futexes in userspace and you are
guaranteed not to exhaust any limit as long as you have memory. That is
an important feature, and the current userspace is relying on it by
assuming that creating mutexes and condition variables is cheap.
Having futex fd would be useful in some cases to be able to integrate
futexes with IO. I did have use cases where I would have liked to have
FUTEX_FD in the past. These cases arise when you already have a thread
that operates on fds and you want to avoid having a separate thread that
blocks on futexes in a similar fashion. But, IMO, that should be an
optional opt-in feature. By far, not every futex needs to have an fd.
For just waiting on multiple futexes, the native support that futex2
provides is superior.
PS: I'm not asking FUTEX_FD to be implemented as part of futex2 API.
futex2 would be great even without it.
From: Nicholas Piggin <npiggin@gmail.com> Date: 2021-06-06 11:59:12
Excerpts from Andrey Semashev's message of June 5, 2021 6:56 pm:
On 6/5/21 4:09 AM, Nicholas Piggin wrote:
quoted
Excerpts from André Almeida's message of June 5, 2021 6:01 am:
quoted
Às 08:36 de 04/06/21, Nicholas Piggin escreveu:
quoted
quoted
I'll be burned at the stake for suggesting it but it would be great if
we could use file descriptors. At least for the shared futex, maybe
private could use a per-process futex allocator. It solves all of the
above, although I'm sure has many of its own problem. It may not play
so nicely with the pthread mutex API because of the whole static
initialiser problem, but the first futex proposal did use fds. But it's
an example of an alternate API.
FDs and futex doesn't play well, because for futex_wait() you need to
tell the kernel the expected value in the futex address to avoid
sleeping in a free lock. FD operations (poll, select) don't have this
`value` argument, so they could sleep forever, but I'm not sure if you
had taken this in consideration.
I had. The futex wait API would take a fd additional. The only
difference is the waitqueue that is used when a sleep or wake is
required is derived from the fd, not from an address.
I think the bigger sticking points would be if it's too heavyweight an
object to use (which could be somewhat mitigated with a simpler ida
allocator although that's difficult to do with shared), and whether libc
could sanely use them due to the static initialiser problem of pthread
mutexes.
The static initialization feature is not the only benefit of the current
futex design, and probably not the most important one. You can work
around the static initialization in userspace, e.g. by initializing fd
to an invalid value and creating a valid fd upon the first use. Although
that would still incur a performance penalty and add a new source of
failure.
Sounds like a serious problem, but maybe it isn't. On the other hand,
maybe we don't have to support pthread mutexes as they are anyway
because futex already does that fairly well.
What is more important is that waiting on fd always requires a kernel
call. This will be terrible for performance of uncontended locks, which
is the majority of time.
No. As I said just before, it would be the same except the waitqueue is
derived from fd rather than address.
Another important point is that a futex that is not being waited on
consumes zero kernel resources while fd is a limited resource even when
not used. You can have millions futexes in userspace and you are
guaranteed not to exhaust any limit as long as you have memory. That is
an important feature, and the current userspace is relying on it by
assuming that creating mutexes and condition variables is cheap.
Is it an important feture? Would 1 byte of kernel memory per uncontended
futex be okay? 10? 100?
I do see it's very nice the current design that requires no
initialization for uncontended, I'm just asking questions to get an idea
of what constraints we're working with. We have a pretty good API
already which can support unlimited uncontended futexes, so I'm
wondering do we really need another very very similar API that doesn't
fix the really difficult problems of the existing one?
Thanks,
Nick
Having futex fd would be useful in some cases to be able to integrate
futexes with IO. I did have use cases where I would have liked to have
FUTEX_FD in the past. These cases arise when you already have a thread
that operates on fds and you want to avoid having a separate thread that
blocks on futexes in a similar fashion. But, IMO, that should be an
optional opt-in feature. By far, not every futex needs to have an fd.
For just waiting on multiple futexes, the native support that futex2
provides is superior.
PS: I'm not asking FUTEX_FD to be implemented as part of futex2 API.
futex2 would be great even without it.
Excerpts from Andrey Semashev's message of June 5, 2021 6:56 pm:
quoted
On 6/5/21 4:09 AM, Nicholas Piggin wrote:
quoted
Excerpts from André Almeida's message of June 5, 2021 6:01 am:
quoted
Às 08:36 de 04/06/21, Nicholas Piggin escreveu:
quoted
quoted
I'll be burned at the stake for suggesting it but it would be great if
we could use file descriptors. At least for the shared futex, maybe
private could use a per-process futex allocator. It solves all of the
above, although I'm sure has many of its own problem. It may not play
so nicely with the pthread mutex API because of the whole static
initialiser problem, but the first futex proposal did use fds. But it's
an example of an alternate API.
FDs and futex doesn't play well, because for futex_wait() you need to
tell the kernel the expected value in the futex address to avoid
sleeping in a free lock. FD operations (poll, select) don't have this
`value` argument, so they could sleep forever, but I'm not sure if you
had taken this in consideration.
I had. The futex wait API would take a fd additional. The only
difference is the waitqueue that is used when a sleep or wake is
required is derived from the fd, not from an address.
I think the bigger sticking points would be if it's too heavyweight an
object to use (which could be somewhat mitigated with a simpler ida
allocator although that's difficult to do with shared), and whether libc
could sanely use them due to the static initialiser problem of pthread
mutexes.
The static initialization feature is not the only benefit of the current
futex design, and probably not the most important one. You can work
around the static initialization in userspace, e.g. by initializing fd
to an invalid value and creating a valid fd upon the first use. Although
that would still incur a performance penalty and add a new source of
failure.
Sounds like a serious problem, but maybe it isn't. On the other hand,
maybe we don't have to support pthread mutexes as they are anyway
because futex already does that fairly well.
quoted
What is more important is that waiting on fd always requires a kernel
call. This will be terrible for performance of uncontended locks, which
is the majority of time.
No. As I said just before, it would be the same except the waitqueue is
derived from fd rather than address.
Sorry, in that case I'm not sure I understand how that would work. You
do need to allocate a fd, do you?
quoted
Another important point is that a futex that is not being waited on
consumes zero kernel resources while fd is a limited resource even when
not used. You can have millions futexes in userspace and you are
guaranteed not to exhaust any limit as long as you have memory. That is
an important feature, and the current userspace is relying on it by
assuming that creating mutexes and condition variables is cheap.
Is it an important feture? Would 1 byte of kernel memory per uncontended
futex be okay? 10? 100?
I do see it's very nice the current design that requires no
initialization for uncontended, I'm just asking questions to get an idea
of what constraints we're working with. We have a pretty good API
already which can support unlimited uncontended futexes, so I'm
wondering do we really need another very very similar API that doesn't
fix the really difficult problems of the existing one?
It does provide the very much needed features that are missing in the
current futex. Namely, more futex sizes and wait for multiple. So the
argument of "why have two similar APIs" is not quite fair. It would be,
if there was feature parity with futex.
I believe, the low cost of a futex is an important feature, and was one
of the reasons for its original design and introduction. Otherwise we
would be using eventfds in mutexes.
One other feature that I didn't mention earlier and which follows from
its "address in memory" design is the ability to use futexes in
process-shared memory. This is important for process-shared pthread
components, too, but has its own value even without this, if you use
futexes directly. With fds, you can't place the fd in a shared memory
since every process needs to have its own fd referring to the same
kernel object, and passing fds cannot be done without a UNIX socket.
This is incompatible with pthreads API design and would require
non-trivial design changes to the applications using futexes directly.
From: Nicholas Piggin <npiggin@gmail.com> Date: 2021-06-08 01:25:45
Excerpts from Andrey Semashev's message of June 6, 2021 11:15 pm:
On 6/6/21 2:57 PM, Nicholas Piggin wrote:
quoted
Excerpts from Andrey Semashev's message of June 5, 2021 6:56 pm:
quoted
On 6/5/21 4:09 AM, Nicholas Piggin wrote:
quoted
Excerpts from André Almeida's message of June 5, 2021 6:01 am:
quoted
Às 08:36 de 04/06/21, Nicholas Piggin escreveu:
quoted
quoted
I'll be burned at the stake for suggesting it but it would be great if
we could use file descriptors. At least for the shared futex, maybe
private could use a per-process futex allocator. It solves all of the
above, although I'm sure has many of its own problem. It may not play
so nicely with the pthread mutex API because of the whole static
initialiser problem, but the first futex proposal did use fds. But it's
an example of an alternate API.
FDs and futex doesn't play well, because for futex_wait() you need to
tell the kernel the expected value in the futex address to avoid
sleeping in a free lock. FD operations (poll, select) don't have this
`value` argument, so they could sleep forever, but I'm not sure if you
had taken this in consideration.
I had. The futex wait API would take a fd additional. The only
difference is the waitqueue that is used when a sleep or wake is
required is derived from the fd, not from an address.
I think the bigger sticking points would be if it's too heavyweight an
object to use (which could be somewhat mitigated with a simpler ida
allocator although that's difficult to do with shared), and whether libc
could sanely use them due to the static initialiser problem of pthread
mutexes.
The static initialization feature is not the only benefit of the current
futex design, and probably not the most important one. You can work
around the static initialization in userspace, e.g. by initializing fd
to an invalid value and creating a valid fd upon the first use. Although
that would still incur a performance penalty and add a new source of
failure.
Sounds like a serious problem, but maybe it isn't. On the other hand,
maybe we don't have to support pthread mutexes as they are anyway
because futex already does that fairly well.
quoted
What is more important is that waiting on fd always requires a kernel
call. This will be terrible for performance of uncontended locks, which
is the majority of time.
No. As I said just before, it would be the same except the waitqueue is
derived from fd rather than address.
Sorry, in that case I'm not sure I understand how that would work. You
do need to allocate a fd, do you?
Yes. As I said, imagine a futex_wait API that also takes a fd. The
wait queue is derived from that fd rather than the hash table.
quoted
quoted
Another important point is that a futex that is not being waited on
consumes zero kernel resources while fd is a limited resource even when
not used. You can have millions futexes in userspace and you are
guaranteed not to exhaust any limit as long as you have memory. That is
an important feature, and the current userspace is relying on it by
assuming that creating mutexes and condition variables is cheap.
Is it an important feture? Would 1 byte of kernel memory per uncontended
futex be okay? 10? 100?
I do see it's very nice the current design that requires no
initialization for uncontended, I'm just asking questions to get an idea
of what constraints we're working with. We have a pretty good API
already which can support unlimited uncontended futexes, so I'm
wondering do we really need another very very similar API that doesn't
fix the really difficult problems of the existing one?
It does provide the very much needed features that are missing in the
current futex. Namely, more futex sizes and wait for multiple. So the
argument of "why have two similar APIs" is not quite fair. It would be,
if there was feature parity with futex.
It does provide some extra features sure, with some straightforward
extension of the existing API. The really interesting or tricky part of
the API is left unchanged though.
My line of thinking is that while we're changing the API anyway, we
should see if it can be changed to help those other problems too.
I believe, the low cost of a futex is an important feature, and was one
of the reasons for its original design and introduction.
It is of course. The first futex proposal did use fds, interestingly.
I didn't look back further into the libc side of that thing, but maybe
I should.
Otherwise we
would be using eventfds in mutexes.
I don't think so, not even if eventfd came before the futex syscall.
One other feature that I didn't mention earlier and which follows from
its "address in memory" design is the ability to use futexes in
process-shared memory. This is important for process-shared pthread
components, too, but has its own value even without this, if you use
futexes directly. With fds, you can't place the fd in a shared memory
since every process needs to have its own fd referring to the same
kernel object, and passing fds cannot be done without a UNIX socket.
This is incompatible with pthreads API design and would require
non-trivial design changes to the applications using futexes directly.
That may be true. file is a natural object to share such a resource, but
the means to share the fd is not so easy. OTOH you could also use a
syscall to open the same file and get a new fd.
Are shared pthread mutexes using existing pthread APIs that are today
implemented okay with futex1 system call a good reason to constrain
futex2 I wonder? Or do we have an opportunity to make a bigger change
to the API so it suffers less from non deterministic latency (for
example)?
I don't want to limit it to just files vs addresses, fds was an example
of something that could solve some of the problems.
Thanks,
Nick
Are shared pthread mutexes using existing pthread APIs that are today
implemented okay with futex1 system call a good reason to constrain
futex2 I wonder? Or do we have an opportunity to make a bigger change
to the API so it suffers less from non deterministic latency (for
example)?
If futex2 is not able to cover futex1 use cases then it cannot be viewed
as a replacement. In the long term this means futex1 cannot be
deprecated and has to be maintained. My impression was that futex1 was
basically unmaintainable(*) and futex2 was an evolution of futex1 so
that users of futex1 could migrate relatively easily and futex1
eventually removed. Maybe my impression was wrong, but I would like to
see futex2 as a replacement and extension of futex1, so the latter can
be deprecated at some point.
In any case, creating a new API should consider requirements of its
potential users. If futex2 is intended to eventually replace futex1 then
all current futex1 users are potential users of futex2. If not, then the
futex2 submission should list its intended users, at least in general
terms, and their requirements that led to the proposed API design.
(*) I use "unmaintainable" in a broad sense here. It exists and works in
newer kernel versions and may receive code changes that are necessary to
keep it working, but maintainers refuse any extensions or modifications
of the code, mostly because of its complexity.
On Tue, Jun 08, 2021 at 02:03:50PM +0300, Andrey Semashev wrote:
On 6/8/21 4:25 AM, Nicholas Piggin wrote:
quoted
Are shared pthread mutexes using existing pthread APIs that are today
implemented okay with futex1 system call a good reason to constrain
futex2 I wonder? Or do we have an opportunity to make a bigger change
to the API so it suffers less from non deterministic latency (for
example)?
If futex2 is not able to cover futex1 use cases then it cannot be viewed as
a replacement. In the long term this means futex1 cannot be deprecated and
has to be maintained. My impression was that futex1 was basically
unmaintainable(*) and futex2 was an evolution of futex1 so that users of
futex1 could migrate relatively easily and futex1 eventually removed. Maybe
my impression was wrong, but I would like to see futex2 as a replacement and
extension of futex1, so the latter can be deprecated at some point.
You can never delete a kernel system call, so even if you "deprecate"
it, it still needs to be supported for forever.
Best of all would be if internally your "futex2" code would replace the
"futex1" code so that there is no two different code bases. That would
be the only sane way forward, having 2 code bases to work with is just
insane.
(*) I use "unmaintainable" in a broad sense here. It exists and works in
newer kernel versions and may receive code changes that are necessary to
keep it working, but maintainers refuse any extensions or modifications of
the code, mostly because of its complexity.
Adding additional complexity for no good reason is not a good idea,
especially if you are asking others to maintain and support that
complexity. Would you want to have to do that work?
So what's keeping the futex2 code from doing all that futex1 does so
that the futex1 code can be deleted internally?
thanks,
greg k-h
From: Peter Zijlstra <peterz@infradead.org> Date: 2021-06-08 11:45:36
On Tue, Jun 08, 2021 at 01:13:30PM +0200, Greg KH wrote:
On Tue, Jun 08, 2021 at 02:03:50PM +0300, Andrey Semashev wrote:
So what's keeping the futex2 code from doing all that futex1 does so
that the futex1 code can be deleted internally?
I'd much rather see it the other way around. Much of what futex2 does
can already be done with the futex1 code-base. And then we can add
features on top.
I've been moaning about this for the past many versions, even older
versions actually implemented some of the new features in futex1,
showing it can be done.
We just wanted a saner futex interface because the existing futex
syscall is a monster and making it even worse seemed like a bad idea.
So *again*: please add the new syscalls on top of futex1 and then
extend. Do not re-implement.
On Tue, Jun 08, 2021 at 01:13:30PM +0200, Greg KH wrote:
quoted
On Tue, Jun 08, 2021 at 02:03:50PM +0300, Andrey Semashev wrote:
So what's keeping the futex2 code from doing all that futex1 does so
that the futex1 code can be deleted internally?
I'd much rather see it the other way around. Much of what futex2 does
can already be done with the futex1 code-base. And then we can add
features on top.
Yeah furthermore, how can futex2 be thought of replacing futex1 in the
future when the PI aspects haven't even been mentioned?
Thanks,
Davidlohr
On Tue, Jun 08, 2021 at 02:03:50PM +0300, Andrey Semashev wrote:
quoted
On 6/8/21 4:25 AM, Nicholas Piggin wrote:
quoted
Are shared pthread mutexes using existing pthread APIs that are today
implemented okay with futex1 system call a good reason to constrain
futex2 I wonder? Or do we have an opportunity to make a bigger change
to the API so it suffers less from non deterministic latency (for
example)?
If futex2 is not able to cover futex1 use cases then it cannot be viewed as
a replacement. In the long term this means futex1 cannot be deprecated and
has to be maintained. My impression was that futex1 was basically
unmaintainable(*) and futex2 was an evolution of futex1 so that users of
futex1 could migrate relatively easily and futex1 eventually removed. Maybe
my impression was wrong, but I would like to see futex2 as a replacement and
extension of futex1, so the latter can be deprecated at some point.
You can never delete a kernel system call, so even if you "deprecate"
it, it still needs to be supported for forever.
If I'm not mistaken, some syscalls were dropped from kernel in the past,
after it was established they are no longer used. So it is not
impossible, though might be more difficult specifically with futex.
Best of all would be if internally your "futex2" code would replace the
"futex1" code so that there is no two different code bases. That would
be the only sane way forward, having 2 code bases to work with is just
insane.
Yes, implementing futex1 in terms of futex2 internally is a possible way
forward. Though I'm not sure it is reasonable to require that to be done
in the initial futex2 submission. This requires all of the futex1
functionality to implemented in futex2 from the start, which I think is
too much to ask. Even with some futex1 features missing, futex2 would be
already very much useful to users, and it is easier to implement the
missing bits incrementally over time.
Also, one other point I'd like to make is that not all futex1 features
might need to be reimplemented if futex2 provides a better alternative.
For example, as a user, I would like to see a different approach to
robust futexes that does not mandate a single user (libc) and allows to
use robust futexes directly.
quoted
(*) I use "unmaintainable" in a broad sense here. It exists and works in
newer kernel versions and may receive code changes that are necessary to
keep it working, but maintainers refuse any extensions or modifications of
the code, mostly because of its complexity.
Adding additional complexity for no good reason is not a good idea,
especially if you are asking others to maintain and support that
complexity. Would you want to have to do that work?
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.
On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
On 6/8/21 2:13 PM, Greg KH wrote:
quoted
On Tue, Jun 08, 2021 at 02:03:50PM +0300, Andrey Semashev wrote:
quoted
On 6/8/21 4:25 AM, Nicholas Piggin wrote:
quoted
Are shared pthread mutexes using existing pthread APIs that are today
implemented okay with futex1 system call a good reason to constrain
futex2 I wonder? Or do we have an opportunity to make a bigger change
to the API so it suffers less from non deterministic latency (for
example)?
If futex2 is not able to cover futex1 use cases then it cannot be viewed as
a replacement. In the long term this means futex1 cannot be deprecated and
has to be maintained. My impression was that futex1 was basically
unmaintainable(*) and futex2 was an evolution of futex1 so that users of
futex1 could migrate relatively easily and futex1 eventually removed. Maybe
my impression was wrong, but I would like to see futex2 as a replacement and
extension of futex1, so the latter can be deprecated at some point.
You can never delete a kernel system call, so even if you "deprecate"
it, it still needs to be supported for forever.
If I'm not mistaken, some syscalls were dropped from kernel in the past,
after it was established they are no longer used. So it is not impossible,
though might be more difficult specifically with futex.
Those syscalls were all "compatible with other obsolete operating
system" syscalls from what I remember. You can still run binaries
built in 1995 just fine on your system today (I have a few around here
somewhere...)
Thinking that you can drop futex() in the next 10+ years is very wishful
thinking given just how slow userspace applications are ever updated,
sorry.
greg k-h
On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
On 6/8/21 2:13 PM, Greg KH wrote:
quoted
On Tue, Jun 08, 2021 at 02:03:50PM +0300, Andrey Semashev wrote:
quoted
On 6/8/21 4:25 AM, Nicholas Piggin wrote:
quoted
Are shared pthread mutexes using existing pthread APIs that are today
implemented okay with futex1 system call a good reason to constrain
futex2 I wonder? Or do we have an opportunity to make a bigger change
to the API so it suffers less from non deterministic latency (for
example)?
If futex2 is not able to cover futex1 use cases then it cannot be viewed as
a replacement. In the long term this means futex1 cannot be deprecated and
has to be maintained. My impression was that futex1 was basically
unmaintainable(*) and futex2 was an evolution of futex1 so that users of
futex1 could migrate relatively easily and futex1 eventually removed. Maybe
my impression was wrong, but I would like to see futex2 as a replacement and
extension of futex1, so the latter can be deprecated at some point.
You can never delete a kernel system call, so even if you "deprecate"
it, it still needs to be supported for forever.
If I'm not mistaken, some syscalls were dropped from kernel in the past,
after it was established they are no longer used. So it is not impossible,
though might be more difficult specifically with futex.
quoted
Best of all would be if internally your "futex2" code would replace the
"futex1" code so that there is no two different code bases. That would
be the only sane way forward, having 2 code bases to work with is just
insane.
Yes, implementing futex1 in terms of futex2 internally is a possible way
forward. Though I'm not sure it is reasonable to require that to be done in
the initial futex2 submission. This requires all of the futex1 functionality
to implemented in futex2 from the start, which I think is too much to ask.
Even with some futex1 features missing, futex2 would be already very much
useful to users, and it is easier to implement the missing bits
incrementally over time.
Then do it the other way around, as Peter points out.
quoted
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?
thanks,
greg k-h
On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
quoted
On 6/8/21 2:13 PM, Greg KH wrote:
quoted
quoted
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:
quoted
On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
quoted
On 6/8/21 2:13 PM, Greg KH wrote:
quoted
quoted
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 Tue, Jun 08, 2021 at 04:18:42PM +0300, Andrey Semashev wrote:
quoted
On 6/8/21 3:35 PM, Greg KH wrote:
quoted
On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
quoted
On 6/8/21 2:13 PM, Greg KH wrote:
quoted
quoted
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.
From: Zebediah Figura <zfigura@codeweavers.com> Date: 2021-06-08 17:24:39
On 6/8/21 8:18 AM, Andrey Semashev wrote:
On 6/8/21 3:35 PM, Greg KH wrote:
quoted
On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
quoted
On 6/8/21 2:13 PM, Greg KH wrote:
quoted
quoted
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.
See [0]. The short version is that we can't use futexes the way that
out-of-tree patch set does, due to compatibility and robustness
problems. I wrote said patch set and I'm currently working on a
different solution for upstreaming.
We also can't exactly use futexes to back WaitOnAddress() directly. We
actually do currently, but for various complex reasons that needs to
change, and none of the proposals for futex2 help the new implementation.
ἔρρωσο,
Zebediah
[0]
https://lore.kernel.org/lkml/dab34fd2-b494-8686-bcd7-68beeba4f386@gmail.com/
From: André Almeida <hidden> Date: 2021-06-08 14:14:56
Hi Greg,
Às 08:13 de 08/06/21, Greg KH escreveu:
On Tue, Jun 08, 2021 at 02:03:50PM +0300, Andrey Semashev wrote:
quoted
On 6/8/21 4:25 AM, Nicholas Piggin wrote:
quoted
Are shared pthread mutexes using existing pthread APIs that are today
implemented okay with futex1 system call a good reason to constrain
futex2 I wonder? Or do we have an opportunity to make a bigger change
to the API so it suffers less from non deterministic latency (for
example)?
If futex2 is not able to cover futex1 use cases then it cannot be viewed as
a replacement. In the long term this means futex1 cannot be deprecated and
has to be maintained. My impression was that futex1 was basically
unmaintainable(*) and futex2 was an evolution of futex1 so that users of
futex1 could migrate relatively easily and futex1 eventually removed. Maybe
my impression was wrong, but I would like to see futex2 as a replacement and
extension of futex1, so the latter can be deprecated at some point.
You can never delete a kernel system call, so even if you "deprecate"
it, it still needs to be supported for forever.
Best of all would be if internally your "futex2" code would replace the
"futex1" code so that there is no two different code bases. That would
be the only sane way forward, having 2 code bases to work with is just
insane.
quoted
(*) I use "unmaintainable" in a broad sense here. It exists and works in
newer kernel versions and may receive code changes that are necessary to
keep it working, but maintainers refuse any extensions or modifications of
the code, mostly because of its complexity.
Adding additional complexity for no good reason is not a good idea,
especially if you are asking others to maintain and support that
complexity. Would you want to have to do that work?
So what's keeping the futex2 code from doing all that futex1 does so
that the futex1 code can be deleted internally?
My very first submission of futex2[0] was just an overlay on top of
futex.c, I didn't get much feedback at that time, but I think this is
what you and Peter are thinking of?
After that, last year at Plumbers' RT MC, I presented a talk called
"futex2: A New Interface" and my conclusion after the discussion on this
talk + responses I got from my FUTEX_WAIT_MULTIPLE patchset[1] was that
this work couldn't be done at futex.c, given how fragile things are
there. futex.c would be "feature freeze" and no new major changes would
happen there.
This is the context where this new futex2 code base comes from. So,
which one is it? Happy to go either way but I'm getting conflicting
messages here.
Thanks,
André
[0]
https://lore.kernel.org/lkml/20200612185122.327860-2-andrealmeid@collabora.com/
[1]
https://lore.kernel.org/lkml/20200213214525.183689-1-andrealmeid@collabora.com/
From: André Almeida <hidden> Date: 2021-06-07 15:41:29
Às 22:09 de 04/06/21, Nicholas Piggin escreveu:
Excerpts from André Almeida's message of June 5, 2021 6:01 am:
quoted
Às 08:36 de 04/06/21, Nicholas Piggin escreveu:
quoted
Excerpts from André Almeida's message of June 4, 2021 5:59 am:
- Did you consider a wakev interface? An example is a read-write mutex
which has read-blocking futexes split (e.g., per-node) for scalability
then the writer may unlock and wake all readers with one call. We
actually have some scalability challenges of this nature with certain
large database programs.
Not really, I haven't heard any use case for that until now. It should
be easy to implement it, though, and I think you have an interesting use
case here. Could you point me some of those database programs?
Not source code unfortunately. I know that's not a very good answer, but
they are far ahead of what most open source apps are doing scalability
wise today, and they end up rolling their own complex locking. Hopefully
the example I give is simple enough to understand.
I see, that's makes things a bit harder. I understood the use case and
the wakev can be implemented without affecting the rest of API, so I
think I'll get back to it later, for now.
quoted
quoted
- Are we really keen on squashing node ID into flags in this day and age?
I guess okay but seems like it would be nice to allow a bit more space
in general for the operations. I don't want to turn it into a whole big
multiplexing nightmare again with lots of such flags, or propose
complexity with no code behind it, but I think we need a bit of leeway
for unforeseen locking innovations to be added carefully. The pthread
locking today is still fairly primitive really, I don't think we know
what will work best for the next 10 years.
In the interface that I'd proposed, the node ID isn't part of the flags.
You have a flag FUTEX_FLAG_NUMA, and when that is used, you pass in
`void *uaddr` a pointer to a `struct futex_numa { int value, int hint
}`, where hint should be the node ID you would like to work on, and
value is just the userspace futex. This is documented in more details in
patch 7 "docs: locking: futex2: Add documentation".
If you have any feedback about how this NUMA interface looks like, I
would like to hear.
Also, did something in my writing indicated that the node ID would be
part of the flags? I'll improve this it if so.
Oh I did miss this, thank you. No it wasn't your writing, I think it was
me trying to read through a lot of messages and got confused with some
earlier conversations.
I'll look a bit more at the NUMA interface.
Thanks!
quoted
quoted
One scalability issue we are starting to hit and will only get worse is
futex queue spinlock contention. Perhaps this is better addressed in
userspace but the kernel could play a part so I like to leave some doors
open. One example is that the wait (or wake) side may like to depend not
just on the memory value, but on the success of a cmpxchg to avoid
unqueueing and queueing spuriously, which increases lock contention but
also ends up putting the poor task on the back of the list -- yes RT
priorities can help the realtime case, but non-RT cases can get bad
outlier latencies if lock stealing is allowed (which can be very good
for performance).
Sorry, I'm not sure what do you mean here. Are you proposing to have a
cmpxchg in kernel side, so the lock would be taken by the kernel, and
not by the userspace like it's now?
Yes. Only in slow paths, of course, to reduce starvation / erratic
latencies and spurious wait queue manipulations.
Right, so if we need to go into the kernel to do the cmpxchg, we can't
take a free lock without a syscall, and this goes against the futex
semantics, the "strength" of this interface is to not require context
switch in uncontended cases.
Is not a bad thing itself to go into the kernel to get a lock, other
operating systems do that and if the kernel has more knowledge about who
has the lock, it can even make some smart decisions. But this is not
futex, this probably belongs to another interface (that's probably
slower in the common case than futex).
Actually one other scalability thing while I remember it:
futex_wait currently requires that the lock word is tested under the
queue spin lock (to avoid consuming a wakeup). The problem with this is
that the lock word can be a very hot cache line if you have a lot of
concurrency, so accessing it under the queue lock can increase queue
lock hold time.
I would prefer if the new API was relaxed to avoid this restriction
(e.g., any wait call may consume a wakeup so it's up to userspace to
avoid that if it is a problem).
Maybe I'm wrong, but AFAIK the goal of checking the lock word inside the
spin lock is to avoid sleeping forever (in other words, wrongly assuming
that the lock is taken and missing a wakeup call), not to avoid
consuming wakeups. Or at least this is my interpretation of this long
comment in futex.c:
https://elixir.bootlin.com/linux/v5.12.9/source/kernel/futex.c#L51
So removing this requirement of checking the futex word with the lock
taken could led to undesirable behavior.
quoted
quoted
- The private global futex hash table sucks for various reasons, and
having 128 waiters per thread makes it orders of magnitude easier for
userspace to DoS stuff with hash collisions. NUMA doesn't fix that, the
per process hashing that Thomas suggested does fix the DoS but the
non-deterministic hash collisions still seem to be a problem for real
time response, and at the other end of the scale some apps (certain
databases, etc) can have ten thousand futex waiters at once so birthday
paradox can also lead to guaranteed (low level) variable beahviour
within a single process.
I know the kernel in general is not very robust against this kind of
DoS/nondeterminism, but it's a bit sad to introduce new APIs with the
problem still there. Yes we could address it later, but I think it's
better done first because the solution might influence what the best
syscall API is.
For example the idea of using the address as the handle for the wait
queue _and_ the value is very convenient but hashing is annoying for
all the above reasons and the shared wait queue case is pretty clunky.
It's also constraining in some corner cases to have the wait queue
associated with the address 1:1. For example a type of NUMA mutex might
want to have per-node waitqueues associated with a lock word, and wake
local node waiters 99% of the time. Not trivial to do with futexes and
seems to at least require bouncing of more cache lines, possibly more
atomics, etc.
Could anything else be done?
I wasn't aware that userspace doing DoS is something to be concerned
from the kernel point of view. Is this scenario considering a malicious
actor? If so, there are plenty of resources to be denied, so not sure
how futex could be protected of this. Or is this just a program that
uses tons of futexes?
Both really. AFAIKS one of the efforts that prompted the futex
modernisation work was the RT latency issues from Thomas in 2016 when
the per process table was proposed.
When I first read Thomas proposal for per table process, I thought that
the main goal there was to solve NUMA locality issues, not RT latency,
but I think you are right. However, re-reading the thread at [0], it
seems that the RT problems where not completely solved in that
interface, maybe the people involved with that patchset can help to shed
some light on it.
Otherwise, this same proposal could be integrated in futex2, given that
we would only need to provide to userland some extra flags and add some
`if`s around the hash table code (in a very similar way the NUMA code
will be implemented in futex2).
[0] https://lore.kernel.org/lkml/20160505204230.932454245@linutronix.de/
quoted
quoted
I'll be burned at the stake for suggesting it but it would be great if
we could use file descriptors. At least for the shared futex, maybe
private could use a per-process futex allocator. It solves all of the
above, although I'm sure has many of its own problem. It may not play
so nicely with the pthread mutex API because of the whole static
initialiser problem, but the first futex proposal did use fds. But it's
an example of an alternate API.
FDs and futex doesn't play well, because for futex_wait() you need to
tell the kernel the expected value in the futex address to avoid
sleeping in a free lock. FD operations (poll, select) don't have this
`value` argument, so they could sleep forever, but I'm not sure if you
had taken this in consideration.
I had. The futex wait API would take a fd additional. The only
difference is the waitqueue that is used when a sleep or wake is
required is derived from the fd, not from an address.
I think the bigger sticking points would be if it's too heavyweight an
object to use (which could be somewhat mitigated with a simpler ida
allocator although that's difficult to do with shared), and whether libc
could sanely use them due to the static initialiser problem of pthread
mutexes.
Thanks,
Nick
From: Nicholas Piggin <npiggin@gmail.com> Date: 2021-06-08 01:32:54
Excerpts from André Almeida's message of June 8, 2021 1:40 am:
Às 22:09 de 04/06/21, Nicholas Piggin escreveu:
quoted
Excerpts from André Almeida's message of June 5, 2021 6:01 am:
quoted
Às 08:36 de 04/06/21, Nicholas Piggin escreveu:
quoted
Excerpts from André Almeida's message of June 4, 2021 5:59 am:
- Did you consider a wakev interface? An example is a read-write mutex
which has read-blocking futexes split (e.g., per-node) for scalability
then the writer may unlock and wake all readers with one call. We
actually have some scalability challenges of this nature with certain
large database programs.
Not really, I haven't heard any use case for that until now. It should
be easy to implement it, though, and I think you have an interesting use
case here. Could you point me some of those database programs?
Not source code unfortunately. I know that's not a very good answer, but
they are far ahead of what most open source apps are doing scalability
wise today, and they end up rolling their own complex locking. Hopefully
the example I give is simple enough to understand.
I see, that's makes things a bit harder. I understood the use case and
the wakev can be implemented without affecting the rest of API, so I
think I'll get back to it later, for now.
Yeah that's fine.
quoted
quoted
quoted
- Are we really keen on squashing node ID into flags in this day and age?
I guess okay but seems like it would be nice to allow a bit more space
in general for the operations. I don't want to turn it into a whole big
multiplexing nightmare again with lots of such flags, or propose
complexity with no code behind it, but I think we need a bit of leeway
for unforeseen locking innovations to be added carefully. The pthread
locking today is still fairly primitive really, I don't think we know
what will work best for the next 10 years.
In the interface that I'd proposed, the node ID isn't part of the flags.
You have a flag FUTEX_FLAG_NUMA, and when that is used, you pass in
`void *uaddr` a pointer to a `struct futex_numa { int value, int hint
}`, where hint should be the node ID you would like to work on, and
value is just the userspace futex. This is documented in more details in
patch 7 "docs: locking: futex2: Add documentation".
If you have any feedback about how this NUMA interface looks like, I
would like to hear.
Also, did something in my writing indicated that the node ID would be
part of the flags? I'll improve this it if so.
Oh I did miss this, thank you. No it wasn't your writing, I think it was
me trying to read through a lot of messages and got confused with some
earlier conversations.
I'll look a bit more at the NUMA interface.
Thanks!
quoted
quoted
quoted
One scalability issue we are starting to hit and will only get worse is
futex queue spinlock contention. Perhaps this is better addressed in
userspace but the kernel could play a part so I like to leave some doors
open. One example is that the wait (or wake) side may like to depend not
just on the memory value, but on the success of a cmpxchg to avoid
unqueueing and queueing spuriously, which increases lock contention but
also ends up putting the poor task on the back of the list -- yes RT
priorities can help the realtime case, but non-RT cases can get bad
outlier latencies if lock stealing is allowed (which can be very good
for performance).
Sorry, I'm not sure what do you mean here. Are you proposing to have a
cmpxchg in kernel side, so the lock would be taken by the kernel, and
not by the userspace like it's now?
Yes. Only in slow paths, of course, to reduce starvation / erratic
latencies and spurious wait queue manipulations.
Right, so if we need to go into the kernel to do the cmpxchg, we can't
take a free lock without a syscall,
Yes you can.
and this goes against the futex
semantics, the "strength" of this interface is to not require context
switch in uncontended cases.
Is not a bad thing itself to go into the kernel to get a lock, other
operating systems do that and if the kernel has more knowledge about who
has the lock, it can even make some smart decisions. But this is not
futex, this probably belongs to another interface (that's probably
slower in the common case than futex).
quoted
Actually one other scalability thing while I remember it:
futex_wait currently requires that the lock word is tested under the
queue spin lock (to avoid consuming a wakeup). The problem with this is
that the lock word can be a very hot cache line if you have a lot of
concurrency, so accessing it under the queue lock can increase queue
lock hold time.
I would prefer if the new API was relaxed to avoid this restriction
(e.g., any wait call may consume a wakeup so it's up to userspace to
avoid that if it is a problem).
Maybe I'm wrong, but AFAIK the goal of checking the lock word inside the
spin lock is to avoid sleeping forever (in other words, wrongly assuming
that the lock is taken and missing a wakeup call), not to avoid
consuming wakeups. Or at least this is my interpretation of this long
comment in futex.c:
https://elixir.bootlin.com/linux/v5.12.9/source/kernel/futex.c#L51
So removing this requirement of checking the futex word with the lock
taken could led to undesirable behavior.
No, there are two requirements. Obviously you need to avoid the missed
wakeup at minimum. You don't need to check under the lock unless you
want to avoid consuming an extra wakeup though (it can possibly be done
in more complex ways like you detect if you took a wakeup and if so then
look at the queue and see if you can pass it on, or have some extra flag
to signal you are ready for wake up, but those all seem more complex and
fragile and possibly have weird corner cases, better to just set out
that userspace should deal with it).
quoted
quoted
quoted
- The private global futex hash table sucks for various reasons, and
having 128 waiters per thread makes it orders of magnitude easier for
userspace to DoS stuff with hash collisions. NUMA doesn't fix that, the
per process hashing that Thomas suggested does fix the DoS but the
non-deterministic hash collisions still seem to be a problem for real
time response, and at the other end of the scale some apps (certain
databases, etc) can have ten thousand futex waiters at once so birthday
paradox can also lead to guaranteed (low level) variable beahviour
within a single process.
I know the kernel in general is not very robust against this kind of
DoS/nondeterminism, but it's a bit sad to introduce new APIs with the
problem still there. Yes we could address it later, but I think it's
better done first because the solution might influence what the best
syscall API is.
For example the idea of using the address as the handle for the wait
queue _and_ the value is very convenient but hashing is annoying for
all the above reasons and the shared wait queue case is pretty clunky.
It's also constraining in some corner cases to have the wait queue
associated with the address 1:1. For example a type of NUMA mutex might
want to have per-node waitqueues associated with a lock word, and wake
local node waiters 99% of the time. Not trivial to do with futexes and
seems to at least require bouncing of more cache lines, possibly more
atomics, etc.
Could anything else be done?
I wasn't aware that userspace doing DoS is something to be concerned
from the kernel point of view. Is this scenario considering a malicious
actor? If so, there are plenty of resources to be denied, so not sure
how futex could be protected of this. Or is this just a program that
uses tons of futexes?
Both really. AFAIKS one of the efforts that prompted the futex
modernisation work was the RT latency issues from Thomas in 2016 when
the per process table was proposed.
When I first read Thomas proposal for per table process, I thought that
the main goal there was to solve NUMA locality issues, not RT latency,
but I think you are right. However, re-reading the thread at [0], it
seems that the RT problems where not completely solved in that
interface, maybe the people involved with that patchset can help to shed
some light on it.
Otherwise, this same proposal could be integrated in futex2, given that
we would only need to provide to userland some extra flags and add some
`if`s around the hash table code (in a very similar way the NUMA code
will be implemented in futex2).
[0] https://lore.kernel.org/lkml/20160505204230.932454245@linutronix.de/
Right. The accidental collisions within a process (or
accidental/deliberate collisions with shared futex) problems remain.
Thanks,
Nick
Actually one other scalability thing while I remember it:
futex_wait currently requires that the lock word is tested under the
queue spin lock (to avoid consuming a wakeup). The problem with this is
that the lock word can be a very hot cache line if you have a lot of
concurrency, so accessing it under the queue lock can increase queue
lock hold time.
I would prefer if the new API was relaxed to avoid this restriction
(e.g., any wait call may consume a wakeup so it's up to userspace to
avoid that if it is a problem).
Maybe I'm wrong, but AFAIK the goal of checking the lock word inside the
spin lock is to avoid sleeping forever (in other words, wrongly assuming
that the lock is taken and missing a wakeup call), not to avoid
consuming wakeups. Or at least this is my interpretation of this long
comment in futex.c:
https://elixir.bootlin.com/linux/v5.12.9/source/kernel/futex.c#L51
I think what Nick is referring to is that futex_wait() could return 0
instead of EAGAIN upon a uval != val condition if the check is done
without the hb lock. The value could have changed between when userspace
did the condition check and called into futex(2) to block in the slowpath.
But such spurious scenarios should be pretty rare, and while I agree that
the cacheline can be hot, I'm not sure how much of a performance issue this
really is(?), compared to other issues, certainly not to govern futex2
design. Changing such semantics would be a _huge_ difference between futex1
and futex2.
At least compared, for example, to the hb collisions serializing independent
futexes, affecting both performance and determinism. And I agree that a new
interface should address this problem - albeit most of the workloads I have
seen in production use but a handful of futexes and larger thread counts.
One thing that crossed my mind (but have not actually sat down to look at)
would be to use rlhastables for the dynamic resizing, but of course that would
probably add a decent amount of overhead to the simple hashing we currently have.
Thanks,
Davidlohr
From: Nicholas Piggin <npiggin@gmail.com> Date: 2021-06-08 04:46:54
Excerpts from Davidlohr Bueso's message of June 8, 2021 12:33 pm:
On Mon, 07 Jun 2021, Andr� Almeida wrote:
quoted
Às 22:09 de 04/06/21, Nicholas Piggin escreveu:
quoted
Actually one other scalability thing while I remember it:
futex_wait currently requires that the lock word is tested under the
queue spin lock (to avoid consuming a wakeup). The problem with this is
that the lock word can be a very hot cache line if you have a lot of
concurrency, so accessing it under the queue lock can increase queue
lock hold time.
I would prefer if the new API was relaxed to avoid this restriction
(e.g., any wait call may consume a wakeup so it's up to userspace to
avoid that if it is a problem).
Maybe I'm wrong, but AFAIK the goal of checking the lock word inside the
spin lock is to avoid sleeping forever (in other words, wrongly assuming
that the lock is taken and missing a wakeup call), not to avoid
consuming wakeups. Or at least this is my interpretation of this long
comment in futex.c:
https://elixir.bootlin.com/linux/v5.12.9/source/kernel/futex.c#L51
I think what Nick is referring to is that futex_wait() could return 0
instead of EAGAIN upon a uval != val condition if the check is done
without the hb lock. The value could have changed between when userspace
did the condition check and called into futex(2) to block in the slowpath.
I just mean the check could be done after queueing ourselves on the wait
queue (and unlocking the waitqueue lock, not checking while holding the
lock). That is the standard pattern used everywhere else by the kernel:
prepare_to_wait() /* -> lock; add_wait_queue; unlock; */
check_again();
schedule();
It can still return EAGAIN if there is a reasonable use for it, but I'd
be wary about user code that cares about this -- it's racy you could
arrive right before the value changes or right after it changes, so any
user code checking this I would be suspicious of (I'm willing to see a
use case that really cares).
But such spurious scenarios should be pretty rare, and while I agree that
the cacheline can be hot, I'm not sure how much of a performance issue this
really is(?),
It's not a spurious anything. The problem is the contention on the
lock word cacheline means it can take a relatively long time just to perform
that one load instruction. Mandating that it must be done while holding the
lock translates to increased lock hold times.
This matters particularly in situations that have lock stealing,
optimistic spinning, reader-writer locks or more exotic kind of things
that allow some common types of critical section to go through while others
are blocking. And partiuclarly when such things hash collide on other
futexes that share the same hash lock.
compared to other issues, certainly not to govern futex2
design. Changing such semantics would be a _huge_ difference between futex1
and futex2.
futex1 behaviour should not govern futex2 design. That's the only nice
thing you get with an API change, so we should take full advantage of
it. I'm not saying make changes for no reason, but I gave a reason, so
that should be countered with a better reason to not change.
Thanks,
Nick
At least compared, for example, to the hb collisions serializing independent
futexes, affecting both performance and determinism. And I agree that a new
interface should address this problem - albeit most of the workloads I have
seen in production use but a handful of futexes and larger thread counts.
One thing that crossed my mind (but have not actually sat down to look at)
would be to use rlhastables for the dynamic resizing, but of course that would
probably add a decent amount of overhead to the simple hashing we currently have.
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2021-06-08 12:26:30
On 2021-06-07 12:40:54 [-0300], André Almeida wrote:
When I first read Thomas proposal for per table process, I thought that
the main goal there was to solve NUMA locality issues, not RT latency,
but I think you are right. However, re-reading the thread at [0], it
seems that the RT problems where not completely solved in that
interface, maybe the people involved with that patchset can help to shed
some light on it.
Otherwise, this same proposal could be integrated in futex2, given that
we would only need to provide to userland some extra flags and add some
`if`s around the hash table code (in a very similar way the NUMA code
will be implemented in futex2).
There are slides at [0] describing some attempts and the kernel tree [1]
from that time.
The process-table solves the problem to some degree that two random
process don't collide on the same hash bucket. But as Peter Zijlstra
pointed out back then two threads from the same task could collide on
the same hash bucket (and with ASLR not always). So the collision is
there but limited and this was not perfect.
All the attempts with API extensions didn't go well because glibc did
not want to change a bit. This starts with a mutex that has a static
initializer which has to work (I don't remember why the first
pthread_mutex_lock() could not fail with -ENOMEM but there was
something) and ends with glibc's struct mutex which is full and has no
room for additional data storage.
The additional data in user's struct mutex + init would have the benefit
that instead uaddr (which is hashed for the in-kernel lookup) a cookie
could be used for the hash-less lookup (and NUMA pointer where memory
should be stored).
So. We couldn't change a thing back then so nothing did happen. We
didn't want to create a new interface and a library implementing it plus
all the functionality around it (like pthread_cond, phtread_barrier, …).
Not to mention that if glibc continues to use the "old" locking
internally then the application is still affected by the hash-collision
locking (or the NUMA problem) should it block on the lock.
[0] https://linutronix.de/PDF/2016_futex_Siewior.pdf
[1] https://git.kernel.org/pub/scm/linux/kernel/git/bigeasy/linux-futex.git/
Sebastian
From: Peter Zijlstra <peterz@infradead.org> Date: 2021-06-08 14:24:28
On Tue, Jun 08, 2021 at 02:26:22PM +0200, Sebastian Andrzej Siewior wrote:
On 2021-06-07 12:40:54 [-0300], André Almeida wrote:
quoted
When I first read Thomas proposal for per table process, I thought that
the main goal there was to solve NUMA locality issues, not RT latency,
but I think you are right. However, re-reading the thread at [0], it
seems that the RT problems where not completely solved in that
interface, maybe the people involved with that patchset can help to shed
some light on it.
Otherwise, this same proposal could be integrated in futex2, given that
we would only need to provide to userland some extra flags and add some
`if`s around the hash table code (in a very similar way the NUMA code
will be implemented in futex2).
There are slides at [0] describing some attempts and the kernel tree [1]
from that time.
The process-table solves the problem to some degree that two random
process don't collide on the same hash bucket. But as Peter Zijlstra
pointed out back then two threads from the same task could collide on
the same hash bucket (and with ASLR not always). So the collision is
there but limited and this was not perfect.
All the attempts with API extensions didn't go well because glibc did
not want to change a bit. This starts with a mutex that has a static
initializer which has to work (I don't remember why the first
pthread_mutex_lock() could not fail with -ENOMEM but there was
something) and ends with glibc's struct mutex which is full and has no
room for additional data storage.
The additional data in user's struct mutex + init would have the benefit
that instead uaddr (which is hashed for the in-kernel lookup) a cookie
could be used for the hash-less lookup (and NUMA pointer where memory
should be stored).
So. We couldn't change a thing back then so nothing did happen. We
didn't want to create a new interface and a library implementing it plus
all the functionality around it (like pthread_cond, phtread_barrier, …).
Not to mention that if glibc continues to use the "old" locking
internally then the application is still affected by the hash-collision
locking (or the NUMA problem) should it block on the lock.
There's more futex users than glibc, and some of them are really hurting
because of the NUMA issue. Oracle used to (I've no idea what they do or
do not do these days) use sysvsem because the futex hash table was a
massive bottleneck for them.
And as Nick said, other vendors are having the same problems.
And if you don't extend the futex to store the nid you put the waiter in
(see all the problems above) you will have to do wakeups on all nodes,
which is both slower than it is today, and scales possibly even worse.
The whole numa-aware qspinlock saga is in part because of futex.
That said; if we're going to do the whole futex-vector thing, we really
do need a new interface, because the futex multiplex monster is about to
crumble (see the fun wrt timeouts for example).
And if we're going to do a new interface, we ought to make one that can
solve all these problems. Now, ideally glibc will bring forth some
opinions, but if they don't want to play, we'll go back to the good old
days of non-standard locking libraries.. we're halfway there already due
to glibc not wanting to break with POSIX were we know POSIX was just
dead wrong broken.
See: https://github.com/dvhart/librtpi
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2021-06-08 14:58:01
On 2021-06-08 16:23:45 [+0200], Peter Zijlstra wrote:
There's more futex users than glibc, and some of them are really hurting
because of the NUMA issue. Oracle used to (I've no idea what they do or
do not do these days) use sysvsem because the futex hash table was a
massive bottleneck for them.
And as Nick said, other vendors are having the same problems.
I just wanted to do a brief summary of last events. The implementation
tglx did with the cookie resulting in a quick lookup did not have any
downsides except that the user-API had to change glibc couldn't. So if
we are back to square one why not start with that.
And if you don't extend the futex to store the nid you put the waiter in
(see all the problems above) you will have to do wakeups on all nodes,
which is both slower than it is today, and scales possibly even worse.
The whole numa-aware qspinlock saga is in part because of futex.
sure.
That said; if we're going to do the whole futex-vector thing, we really
do need a new interface, because the futex multiplex monster is about to
crumble (see the fun wrt timeouts for example).
This might have been a series of unfortunate events leading to this. The
sad part is that glibc has a comment that the kernel does not support
this and nobody bother to change it (until recently).
And if we're going to do a new interface, we ought to make one that can
solve all these problems. Now, ideally glibc will bring forth some
opinions, but if they don't want to play, we'll go back to the good old
days of non-standard locking libraries.. we're halfway there already due
to glibc not wanting to break with POSIX were we know POSIX was just
dead wrong broken.
See: https://github.com/dvhart/librtpi
I'm aware of that, I hacked on it, too :) This was the unfortunate
result of a ~8y old bug which was not fixed instead and part of the code
was rewritten and a bit-spinlock was added in user-land. You may
remember the discussion regarding spins in userland…
That said, REQUEUE_PI is no longer used by glibc.
Sebastian
From: André Almeida <hidden> Date: 2021-06-08 15:04:33
Às 11:23 de 08/06/21, Peter Zijlstra escreveu:
On Tue, Jun 08, 2021 at 02:26:22PM +0200, Sebastian Andrzej Siewior wrote:
quoted
On 2021-06-07 12:40:54 [-0300], André Almeida wrote:
quoted
When I first read Thomas proposal for per table process, I thought that
the main goal there was to solve NUMA locality issues, not RT latency,
but I think you are right. However, re-reading the thread at [0], it
seems that the RT problems where not completely solved in that
interface, maybe the people involved with that patchset can help to shed
some light on it.
Otherwise, this same proposal could be integrated in futex2, given that
we would only need to provide to userland some extra flags and add some
`if`s around the hash table code (in a very similar way the NUMA code
will be implemented in futex2).
There are slides at [0] describing some attempts and the kernel tree [1]
from that time.
The process-table solves the problem to some degree that two random
process don't collide on the same hash bucket. But as Peter Zijlstra
pointed out back then two threads from the same task could collide on
the same hash bucket (and with ASLR not always). So the collision is
there but limited and this was not perfect.
All the attempts with API extensions didn't go well because glibc did
not want to change a bit. This starts with a mutex that has a static
initializer which has to work (I don't remember why the first
pthread_mutex_lock() could not fail with -ENOMEM but there was
something) and ends with glibc's struct mutex which is full and has no
room for additional data storage.
The additional data in user's struct mutex + init would have the benefit
that instead uaddr (which is hashed for the in-kernel lookup) a cookie
could be used for the hash-less lookup (and NUMA pointer where memory
should be stored).
So. We couldn't change a thing back then so nothing did happen. We
didn't want to create a new interface and a library implementing it plus
all the functionality around it (like pthread_cond, phtread_barrier, …).
Not to mention that if glibc continues to use the "old" locking
internally then the application is still affected by the hash-collision
locking (or the NUMA problem) should it block on the lock.
There's more futex users than glibc, and some of them are really hurting
because of the NUMA issue. Oracle used to (I've no idea what they do or
do not do these days) use sysvsem because the futex hash table was a
massive bottleneck for them.
And as Nick said, other vendors are having the same problems.
Since we're talking about NUMA, which userspace communities would be
able to provide feedback about the futex2() NUMA-aware feature, to check
if this interface would help solving those issues?
And if you don't extend the futex to store the nid you put the waiter in
(see all the problems above) you will have to do wakeups on all nodes,
which is both slower than it is today, and scales possibly even worse.
The whole numa-aware qspinlock saga is in part because of futex.
That said; if we're going to do the whole futex-vector thing, we really
do need a new interface, because the futex multiplex monster is about to
crumble (see the fun wrt timeouts for example).
And if we're going to do a new interface, we ought to make one that can
solve all these problems. Now, ideally glibc will bring forth some
opinions, but if they don't want to play, we'll go back to the good old
days of non-standard locking libraries.. we're halfway there already due
to glibc not wanting to break with POSIX were we know POSIX was just
dead wrong broken.
See: https://github.com/dvhart/librtpi
All the attempts with API extensions didn't go well because glibc did
not want to change a bit. This starts with a mutex that has a static
initializer which has to work (I don't remember why the first
pthread_mutex_lock() could not fail with -ENOMEM but there was
something) and ends with glibc's struct mutex which is full and has no
room for additional data storage.
Yes, we have binary compatibility constraints that prevents us to simply
broken old binaries. This is quite true for static initialization,
which imposes even harder constraints, different than the pthread_mutex_t
size where we can workaround with symbols versioning. But even then we hear
from users that out pthread_mutex_t is still way larger, specially for
fine grained locking so I am not sure if we do want to extend it.
That said; if we're going to do the whole futex-vector thing, we really
do need a new interface, because the futex multiplex monster is about to
crumble (see the fun wrt timeouts for example).
And if we're going to do a new interface, we ought to make one that can
solve all these problems. Now, ideally glibc will bring forth some
opinions, but if they don't want to play, we'll go back to the good old
days of non-standard locking libraries.. we're halfway there already due
to glibc not wanting to break with POSIX were we know POSIX was just
dead wrong broken.
See: https://github.com/dvhart/librtpi
You are right, we don't really want to break POSIX requirements in this
regard because users constantly come with scenarios where they do expect
our implementation to be conformant [1]. And even now, there are case we
don't get it fully right [2] and it is really hard to fix such issues.
If I recall correctly from a recent plumber couple of years ago about
the librtpi, the presents stated their implement do not follow POSIX
standard by design. It suits then for their required work, but it is
not what we really aim for glibc. We *might* try to provide as an
extension, but even then I am not if it would be fully possible due
API constraints.
So, regarding the futex2 we might try to support it eventually; but if
this newer interface is not a really a superset of futex1 we won't
put much effort. Supporting newer syscall requires an extra effort from
glibc, we need to keep fallback for older ones in case the kernel is
too old and it also imposes runtime costs.
Also currently we don't have a specific usage. The proposed patch to
add the 'pthread_mutex_lock_any' and 'pthreada_timedlock_any' [3]
also did not gave much detail in realword usages or how it can be
leveraged.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=13165
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=25847
[3] https://sourceware.org/pipermail/libc-alpha/2019-July/105422.html
From: David Laight <hidden> Date: 2021-06-09 16:26:20
From: Peter Zijlstra
Sent: 08 June 2021 15:24
...
And if we're going to do a new interface, we ought to make one that can
solve all these problems. Now, ideally glibc will bring forth some
opinions, but if they don't want to play, we'll go back to the good old
days of non-standard locking libraries.. we're halfway there already due
to glibc not wanting to break with POSIX were we know POSIX was just
dead wrong broken.
I had a problem with pthread_broadcast().
I've got multiple threads all bound to different cpu and
I really do want to wake them all up at once.
Now, I know they'll spin on the mutex for a bit - but that
is soon released (the 'adaptive' spin is probably long enough).
But what actually happens (probably because of the way glibc
is constrained by the futext system call) is:
1) The first thread is woken.
2) It's cpu comes out of sleep.
3) Once running it wakes the second thread.
4) It's cpu comes out of sleep.
...
So you get a very slow ripple of the threads starting.
Worse still, if the thread can't be scheduled (eg because
its cpu is running all the network stack softint code)
then none of the later threads start running.
I've mitigated it by using a separate cv for each thread
and looping to wake them all - but it shouldn't really
be necessary.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)