On Thu, Mar 05, 2020 at 01:14:17PM -0300, André Almeida wrote:
sys_futex_wait(void *uaddr, u64 val, unsigned long flags, ktime_t *timo); struct futex_wait { void *uaddr; u64 val; u64 flags; }; sys_futex_waitv(struct futex_wait *waiters, unsigned int nr_waiters, u64 flags, ktime_t *timo); sys_futex_wake(void *uaddr, unsigned int nr, u64 flags); sys_futex_cmp_requeue(void *uaddr1, void *uaddr2, unsigned int nr_wake, unsigned int nr_requeue, u64 cmpval, unsigned long flags);
And that makes 7 arguments for cmp_requeue, which can't be. Maybe we if combine nr_wake and nr_requeue in one as 2 u16... ?
And then we need to go detector if the platform supports it or not..
Thanks everyone for the feedback around our mechanism. Are the performance benefits of implementing a syscall to wait on a single futex significant enough to maintain it instead of just using `sys_futex_waitv()` with `nr_waiters = 1`? If we join both cases in a single interface, we may even add a new member for NUMA hint in `struct futex_wait`.
My consideration was that avoiding the get_user/copy_from_user might become measurable on !PTI systems with SMAP.
But someone would have to build it and measure it before we can be sure of course.