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

On Wed, 2 May 2018, Peter Zijlstra wrote: > On Wed, May 02, 2018 at 06:27:22PM +, Daniel Colascione wrote: > > On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra wrote: > > >> On Wed, May 02, 2018 at 03:53:47AM +, Daniel Colascione wrote: > > > > Suppose we make a

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

On Wed, 2 May 2018, Peter Zijlstra wrote: > On Wed, May 02, 2018 at 06:27:22PM +, Daniel Colascione wrote: > > On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra wrote: > > >> On Wed, May 02, 2018 at 03:53:47AM +, Daniel Colascione wrote: > > > > Suppose we make a userspace mutex implemented

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

Hey - I think the ideas Daniel brings up here are interesting -- specifically the notion that a thread could set a "pre-sleep wish" to signal it's sleeping. As this conversation shows I think there's a fair bit of depth to that. For example, the FUTEX_LOCK is an alternative approach. Another

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

Hey - I think the ideas Daniel brings up here are interesting -- specifically the notion that a thread could set a "pre-sleep wish" to signal it's sleeping. As this conversation shows I think there's a fair bit of depth to that. For example, the FUTEX_LOCK is an alternative approach. Another

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

- On May 3, 2018, at 12:22 PM, Daniel Colascione dan...@google.com wrote: > On Thu, May 3, 2018 at 9:12 AM Mathieu Desnoyers < > mathieu.desnoy...@efficios.com> wrote: >> By the way, if we eventually find a way to enhance user-space mutexes in > the >> fashion you describe here, it would

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

- On May 3, 2018, at 12:22 PM, Daniel Colascione dan...@google.com wrote: > On Thu, May 3, 2018 at 9:12 AM Mathieu Desnoyers < > mathieu.desnoy...@efficios.com> wrote: >> By the way, if we eventually find a way to enhance user-space mutexes in > the >> fashion you describe here, it would

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

Hi Daniel, Nice to have this healthy discussion about pros/cons. Adding Waiman to the discussion as well. Curious to hear what Waiman and Peter think about all this. Some more comments inline. On Thu, May 3, 2018 at 10:19 AM Daniel Colascione wrote: > On Thu, May 3, 2018 at

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

Hi Daniel, Nice to have this healthy discussion about pros/cons. Adding Waiman to the discussion as well. Curious to hear what Waiman and Peter think about all this. Some more comments inline. On Thu, May 3, 2018 at 10:19 AM Daniel Colascione wrote: > On Thu, May 3, 2018 at 9:48 AM Joel

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

On Thu, May 3, 2018 at 9:48 AM Joel Fernandes wrote: > > > can skip the manual schedule we were going to perform. > > By the way, if we eventually find a way to enhance user-space mutexes in > the > > fashion you describe here, it would belong to another TLS area, and would >

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

On Thu, May 3, 2018 at 9:48 AM Joel Fernandes wrote: > > > can skip the manual schedule we were going to perform. > > By the way, if we eventually find a way to enhance user-space mutexes in > the > > fashion you describe here, it would belong to another TLS area, and would > > be registered by

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

On Thu, May 3, 2018 at 9:12 AM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > - On May 2, 2018, at 12:07 PM, Daniel Colascione dan...@google.com wrote: > > On Wed, May 2, 2018 at 9:03 AM Mathieu Desnoyers < > > mathieu.desnoy...@efficios.com> wrote: > > > >> - On May 1,

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

On Thu, May 3, 2018 at 9:12 AM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > - On May 2, 2018, at 12:07 PM, Daniel Colascione dan...@google.com wrote: > > On Wed, May 2, 2018 at 9:03 AM Mathieu Desnoyers < > > mathieu.desnoy...@efficios.com> wrote: > > > >> - On May 1,

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

On Thu, May 3, 2018 at 9:12 AM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > By the way, if we eventually find a way to enhance user-space mutexes in the > fashion you describe here, it would belong to another TLS area, and would > be registered by another system call than rseq. I

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

On Thu, May 3, 2018 at 9:12 AM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > By the way, if we eventually find a way to enhance user-space mutexes in the > fashion you describe here, it would belong to another TLS area, and would > be registered by another system call than rseq. I

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

- On May 2, 2018, at 12:07 PM, Daniel Colascione dan...@google.com wrote: > On Wed, May 2, 2018 at 9:03 AM Mathieu Desnoyers < > mathieu.desnoy...@efficios.com> wrote: > >> - On May 1, 2018, at 11:53 PM, Daniel Colascione dan...@google.com > wrote: >> [...] >> > >> > I think a small

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

- On May 2, 2018, at 12:07 PM, Daniel Colascione dan...@google.com wrote: > On Wed, May 2, 2018 at 9:03 AM Mathieu Desnoyers < > mathieu.desnoy...@efficios.com> wrote: > >> - On May 1, 2018, at 11:53 PM, Daniel Colascione dan...@google.com > wrote: >> [...] >> > >> > I think a small

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

On Wed, May 02, 2018 at 08:37:13PM +, Daniel Colascione wrote: > > Recursive locks are teh most horrible crap ever. And having the tid in > > What happened to providing mechanism, not policy? > > You can't wish away recursive locking. It's baked into Java and the CLR, > and it's enshrined in

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

On Wed, May 02, 2018 at 08:37:13PM +, Daniel Colascione wrote: > > Recursive locks are teh most horrible crap ever. And having the tid in > > What happened to providing mechanism, not policy? > > You can't wish away recursive locking. It's baked into Java and the CLR, > and it's enshrined in

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

On Wed, 02 May 2018 20:37:13 + Daniel Colascione wrote: > On Wed, May 2, 2018 at 1:23 PM Peter Zijlstra wrote: > > > On Wed, May 02, 2018 at 06:27:22PM +, Daniel Colascione wrote: > > > On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra

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

On Wed, 02 May 2018 20:37:13 + Daniel Colascione wrote: > On Wed, May 2, 2018 at 1:23 PM Peter Zijlstra wrote: > > > On Wed, May 02, 2018 at 06:27:22PM +, Daniel Colascione wrote: > > > On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra > wrote: > > > >> On Wed, May 02, 2018 at

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

On Wed, May 2, 2018 at 1:23 PM Peter Zijlstra wrote: > On Wed, May 02, 2018 at 06:27:22PM +, Daniel Colascione wrote: > > On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra wrote: > > >> On Wed, May 02, 2018 at 03:53:47AM +, Daniel Colascione

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

On Wed, May 2, 2018 at 1:23 PM Peter Zijlstra wrote: > On Wed, May 02, 2018 at 06:27:22PM +, Daniel Colascione wrote: > > On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra wrote: > > >> On Wed, May 02, 2018 at 03:53:47AM +, Daniel Colascione wrote: > > > > Suppose we make a userspace mutex

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

On Wed, May 02, 2018 at 06:27:22PM +, Daniel Colascione wrote: > On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra wrote: > >> On Wed, May 02, 2018 at 03:53:47AM +, Daniel Colascione wrote: > > > Suppose we make a userspace mutex implemented with a lock word having >

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

On Wed, May 02, 2018 at 06:27:22PM +, Daniel Colascione wrote: > On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra wrote: > >> On Wed, May 02, 2018 at 03:53:47AM +, Daniel Colascione wrote: > > > Suppose we make a userspace mutex implemented with a lock word having > three > > > bits:

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

On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra wrote: >> On Wed, May 02, 2018 at 03:53:47AM +, 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

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

On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra wrote: >> On Wed, May 02, 2018 at 03:53:47AM +, 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

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

On Wed, May 02, 2018 at 03:53:47AM +, 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

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

On Wed, May 02, 2018 at 03:53:47AM +, 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

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

On Wed, May 2, 2018 at 9:42 AM Steven Rostedt wrote: > On Wed, 02 May 2018 16:07:48 + > Daniel Colascione wrote: > > Why couldn't we take a page fault just before schedule? The reason we can't > > take a page fault in atomic context is that doing so

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

On Wed, May 2, 2018 at 9:42 AM Steven Rostedt wrote: > On Wed, 02 May 2018 16:07:48 + > Daniel Colascione wrote: > > Why couldn't we take a page fault just before schedule? The reason we can't > > take a page fault in atomic context is that doing so might call schedule. > > Here, we're

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

On Wed, 02 May 2018 16:07:48 + Daniel Colascione wrote: > Why couldn't we take a page fault just before schedule? The reason we can't > take a page fault in atomic context is that doing so might call schedule. > Here, we're about to call schedule _anyway_, so what harm

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

On Wed, 02 May 2018 16:07:48 + Daniel Colascione wrote: > Why couldn't we take a page fault just before schedule? The reason we can't > take a page fault in atomic context is that doing so might call schedule. > Here, we're about to call schedule _anyway_, so what harm does it do to > call

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

On Wed, May 2, 2018 at 9:03 AM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > - On May 1, 2018, at 11:53 PM, Daniel Colascione dan...@google.com wrote: > [...] > > > > I think a small enhancement to rseq would let us build a perfect userspace > > mutex, one that spins on

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

On Wed, May 2, 2018 at 9:03 AM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > - On May 1, 2018, at 11:53 PM, Daniel Colascione dan...@google.com wrote: > [...] > > > > I think a small enhancement to rseq would let us build a perfect userspace > > mutex, one that spins on

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

- On May 1, 2018, at 11:53 PM, Daniel Colascione dan...@google.com wrote: [...] > > I think a small enhancement to rseq would let us build a perfect userspace > mutex, one that spins on lock-acquire only when the lock owner is running > and that sleeps otherwise, freeing userspace from both

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

- On May 1, 2018, at 11:53 PM, Daniel Colascione dan...@google.com wrote: [...] > > I think a small enhancement to rseq would let us build a perfect userspace > mutex, one that spins on lock-acquire only when the lock owner is running > and that sleeps otherwise, freeing userspace from both

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

On Wed, May 02, 2018 at 03:53:47AM +, Daniel Colascione wrote: > The usual approach to "better" is an "adaptive mutex". Such a thing, when > it attempts to acquire a lock another thread owns, spins for some number of > iterations, then falls back to futex. I guess that's a little better than >

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

On Wed, May 02, 2018 at 03:53:47AM +, Daniel Colascione wrote: > The usual approach to "better" is an "adaptive mutex". Such a thing, when > it attempts to acquire a lock another thread owns, spins for some number of > iterations, then falls back to futex. I guess that's a little better than >

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

Hi Mathieu: this work looks very cool. See inline. On Mon, Apr 30, 2018 at 3:48 PM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > Hi, > Here is an updated RFC round of the Restartable Sequences patchset > based on kernel 4.17-rc3. Based on feedback from Linus, I'm introducing >

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

Hi Mathieu: this work looks very cool. See inline. On Mon, Apr 30, 2018 at 3:48 PM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > Hi, > Here is an updated RFC round of the Restartable Sequences patchset > based on kernel 4.17-rc3. Based on feedback from Linus, I'm introducing >

[RFC PATCH for 4.18 00/14] Restartable Sequences

Hi, Here is an updated RFC round of the Restartable Sequences patchset based on kernel 4.17-rc3. Based on feedback from Linus, I'm introducing only the rseq system call, keeping the rest for later. This already enables speeding up the Facebook jemalloc and arm64 PMC read from user-space

[RFC PATCH for 4.18 00/14] Restartable Sequences

Hi, Here is an updated RFC round of the Restartable Sequences patchset based on kernel 4.17-rc3. Based on feedback from Linus, I'm introducing only the rseq system call, keeping the rest for later. This already enables speeding up the Facebook jemalloc and arm64 PMC read from user-space