Re: [RFC PATCH for 4.18 00/14] Restartable Sequences

On Wed, May 02, 2018 at 06:27:22PM +0000, Daniel Colascione wrote:

On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra [off-list ref] wrote:

quoted

quoted

On Wed, May 02, 2018 at 03:53:47AM +0000, Daniel Colascione wrote:
Suppose we make a userspace mutex implemented with a lock word having

three

quoted

quoted

bits: acquired, sleep_mode, and wait_pending, with the rest of the word

not

quoted

quoted

being relevant at the moment.

quoted

So ideally we'd kill FUTEX_WAIT/FUTEX_WAKE for mutexes entirely, and go
with FUTEX_LOCK/FUTEX_UNLOCK that have the same semantics as the
existing FUTEX_LOCK_PI/FUTEX_UNLOCK_PI, namely, the word contains the
owner TID.

That doesn't work if you want to use the rest of the word for something
else, like a recursion count. With FUTEX_WAIT and FUTEX_WAKE, you can make
a lock with two bits.

Recursive locks are teh most horrible crap ever. And having the tid in
the word allows things like kernel based optimistic spins and possibly
PI related things.

quoted

As brought up in the last time we talked about spin loops, why do we
care if the spin loop is in userspace or not? Aside from the whole PTI
thing, the syscall cost was around 150 cycle or so, while a LOCK CMPXCHG
is around 20 cycles. So ~7 spins gets you the cost of entry.

That's pre-KPTI, isn't it?

Yes, and once the hardware gets sorted, we'll be there again. I don't
think we should design interfaces for 'broken' hardware.