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
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 use-cases
21 matches
Mail list logo
