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

On Thu, May 3, 2018 at 9:12 AM Mathieu Desnoyers <
mathieu.desnoyers@efficios.com> wrote:

----- On May 2, 2018, at 12:07 PM, Daniel Colascione dancol@google.com

wrote:

quoted

On Wed, May 2, 2018 at 9:03 AM Mathieu Desnoyers <
mathieu.desnoyers@efficios.com> wrote:

quoted

----- On May 1, 2018, at 11:53 PM, Daniel Colascione dancol@google.com

wrote:

quoted

[...]

quoted

I think a small enhancement to rseq would let us build a perfect

userspace

quoted

quoted

mutex, one that spins on lock-acquire only when the lock owner is

running

quoted

quoted

and that sleeps otherwise, freeing userspace from both specifying

ad-hoc

quoted

quoted

quoted

spin counts and from trying to detect situations in which spinning is
generally pointless.

It'd work like this: in the per-thread rseq data structure, we'd

include a

quoted

quoted

description of a futex operation for the kernel would perform (in the
context of the preempted thread) upon preemption, immediately before
schedule(). If the futex operation itself sleeps, that's no problem:

we

quoted

quoted

quoted

will have still accomplished our goal of running some other thread

instead

quoted

quoted

of the preempted thread.

quoted

Hi Daniel,

quoted

I agree that the problem you are aiming to solve is important. Let's

see

quoted

quoted

what prevents the proposed rseq implementation from doing what you

envision.

quoted

The main issue here is touching userspace immediately before

schedule().

quoted

quoted

At that specific point, it's not possible to take a page fault. In the

proposed

quoted

rseq implementation, we get away with it by raising a task struct flag,

and using

quoted

it in a return to userspace notifier (where we can actually take a

fault), where

quoted

we touch the userspace TLS area.

quoted

If we can find a way to solve this limitation, then the rest of your

design

quoted

makes sense to me.

Thanks for taking a look!

Why couldn't we take a page fault just before schedule? The reason we

can't

quoted

take a page fault in atomic context is that doing so might call

schedule.

quoted

Here, we're about to call schedule _anyway_, so what harm does it do to
call something that might call schedule? If we schedule via that call,

we

quoted

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 another system call than rseq. I proposed a more generic

Right. Also I still don't see any good reason why optimistic spinning in
the kernel with FUTEX_LOCK, as Peter described, can't be used instead of
using the rseq implementation and spinning in userspace, for such a case. I
don't really fully buy that we need to design this interface assuming any
privilege transition level time. If privilege level transitions are slow,
we're going to have bad performance anyway. Unless there's some data to
show that we have to optimistically spin in userspace than the kernel
because its better to do so, we should really stick to using FUTEX_LOCK and
reuse all the work that went into that area for Android and otherwise (and
work with Waiman and others on improving that if there are any problems
with it).

I am excited though about the other synchronization design other than lock
implementation that rseq can help in.

thanks!

- Joel