[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180502172218.GL12180@hirez.programming.kicks-ass.net>
Date: Wed, 2 May 2018 19:22:18 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Daniel Colascione <dancol@...gle.com>
Cc: mathieu.desnoyers@...icios.com, paulmck@...ux.vnet.ibm.com,
boqun.feng@...il.com, luto@...capital.net, davejwatson@...com,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
pjt@...gle.com, Andrew Morton <akpm@...ux-foundation.org>,
linux@....linux.org.uk, tglx@...utronix.de, mingo@...hat.com,
hpa@...or.com, Andrew Hunter <ahh@...gle.com>, andi@...stfloor.org,
cl@...ux.com, bmaurer@...com, rostedt@...dmis.org,
josh@...htriplett.org, torvalds@...ux-foundation.org,
catalin.marinas@....com, will.deacon@....com,
mtk.manpages@...il.com, Joel Fernandes <joelaf@...gle.com>
Subject: Re: [RFC PATCH for 4.18 00/14] Restartable Sequences
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
> bits: acquired, sleep_mode, and wait_pending, with the rest of the word not
> being relevant at the moment.
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.
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.
Powered by blists - more mailing lists