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
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 id
- 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 belon
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 Fernande
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 a
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, 2018
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 pr
- 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 enhan
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
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 03:53:4
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
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: acquire
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 rele
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
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 abou
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 so
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 lock-acq
- 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 sp
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
>
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
> onl
20 matches
Mail list logo
