This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 'simple' futex interface [Was: [PATCH v3 1/4] futex: Implement mechanism to wait on any of several futexes]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Peter Zijlstra <peterz at infradead dot org>
- Cc: "Pierre-Loup A. Griffais" <pgriffais at valvesoftware dot com>, Thomas Gleixner <tglx at linutronix dot de>, André Almeida <andrealmeid at collabora dot com>, linux-kernel at vger dot kernel dot org, kernel at collabora dot com, krisman at collabora dot com, shuah at kernel dot org, linux-kselftest at vger dot kernel dot org, rostedt at goodmis dot org, ryao at gentoo dot org, dvhart at infradead dot org, mingo at redhat dot com, z dot figura12 at gmail dot com, steven at valvesoftware dot com, steven at liquorix dot net, malteskarupke at web dot de, carlos at redhat dot com, adhemerval dot zanella at linaro dot org, libc-alpha at sourceware dot org
- Date: Tue, 03 Mar 2020 14:00:12 +0100
- Subject: Re: 'simple' futex interface [Was: [PATCH v3 1/4] futex: Implement mechanism to wait on any of several futexes]
- References: <20200213214525.183689-1-andrealmeid@collabora.com> <20200213214525.183689-2-andrealmeid@collabora.com> <20200228190717.GM18400@hirez.programming.kicks-ass.net> <20200228194958.GO14946@hirez.programming.kicks-ass.net> <87tv3aflqm.fsf@nanos.tec.linutronix.de> <967d5047-2cb6-d6d8-6107-edb99a4c9696@valvesoftware.com> <87o8thg031.fsf@nanos.tec.linutronix.de> <beb82055-96fa-cb64-a06e-9d7a0946587b@valvesoftware.com> <20200303120050.GC2596@hirez.programming.kicks-ass.net>
* Peter Zijlstra:
> So how about we introduce new syscalls:
>
> sys_futex_wait(void *uaddr, unsigned long val, unsigned long flags, ktime_t *timo);
>
> struct futex_wait {
> void *uaddr;
> unsigned long val;
> unsigned long flags;
> };
> sys_futex_waitv(struct futex_wait *waiters, unsigned int nr_waiters,
> unsigned long flags, ktime_t *timo);
>
> sys_futex_wake(void *uaddr, unsigned int nr, unsigned long flags);
>
> sys_futex_cmp_requeue(void *uaddr1, void *uaddr2, unsigned int nr_wake,
> unsigned int nr_requeue, unsigned long cmpval, unsigned long flags);
>
> Where flags:
>
> - has 2 bits for size: 8,16,32,64
> - has 2 more bits for size (requeue) ??
> - has ... bits for clocks
> - has private/shared
> - has numa
What's the actual type of *uaddr? Does it vary by size (which I assume
is in bits?)? Are there alignment constraints?
These system calls seemed to be type-polymorphic still, which is
problematic for defining a really nice C interface. I would really like
to have a strongly typed interface for this, with a nice struct futex
wrapper type (even if it means that we need four of them).
Will all architectures support all sizes? If not, how do we probe which
size/flags combinations are supported?
> For NUMA I propose that when NUMA_FLAG is set, uaddr-4 will be 'int
> node_id', with the following semantics:
>
> - on WAIT, node_id is read and when 0 <= node_id <= nr_nodes, is
> directly used to index into per-node hash-tables. When -1, it is
> replaced by the current node_id and an smp_mb() is issued before we
> load and compare the @uaddr.
>
> - on WAKE/REQUEUE, it is an immediate index.
Does this mean the first waiter determines the NUMA index, and all
future waiters use the same chain even if they are on different nodes?
I think documenting this as a node index would be a mistake. It could
be an arbitrary hint for locating the corresponding kernel data
structures.
> Any invalid value with result in EINVAL.
Using uaddr-4 is slightly tricky with a 64-bit futex value, due to the
need to maintain alignment and avoid padding.
Thanks,
Florian