Use the regular turnstile interface to lend prio to preempted readers.

[markj]

Summary

epoch's synchronous wait operation tries to bind to CPUs where active
readers are running, so that it can propagate the waiting thread's
priority to preempted readers. This approach has a few problems:

• it can cause the reader to be preempted, which is really the opposite of what we want to do
• the thread might have to wait for a long time if the CPU is monopolized by a high priority thread
• the priority propagation to non-blocked threads does not use the turnstile interface, so it doesn't properly integrate with the existing priority propagation mechanism used by the locking primitives

Try to simplify epoch_block_handler_preempt() by identifying the oldest
active off-CPU reader and making it the owner of a turnstile. Waiting
threads use the turnstile to propagate their scheduling priority; there
is one turnstile per-CPU. Upon exiting the read section, the turnstile
owner takes a slow path to wake up waiters.

This mechanism is not perfect but it is much simpler and avoids the
problems listed above. In some cases priority propagation is not enough
and we'd want a static priority boost to ensure that starved readers can
make progress.

[• hselasky]

I need some time to review this.

[jeff]

I approve of the approach.

sys/kern/subr_epoch.c

488

Why doesn't this retry? You are gambling that the next first thread may be newer than the poll?

When we apply this to SMR we can supply the actual sequence numbers and process the list until we've met our target. epoch could give you a before/after check so you don't avoid blocking on threads you don't need to.

[markj]

sys/kern/subr_epoch.c

488

By returning we effectively trigger a retry. This function is a callback invoked by CK during a poll. I didn't see any particular reason to add another retry here.

[• hselasky]

Does this approach mean that EPOCH enter exit, works best if it is within an mtx_lock() section?

What do you do when EPOCH synchronize wait is not blocked on a mutex?

[• hselasky]

Could you rebase this patch?