On Wed, 25 Oct 2023 18:24:35 +0200[...]
Mateusz Guzik <mjguzik@xxxxxxxxx> wrote:
On Wed, Oct 25, 2023 at 11:42:34AM -0400, Mathieu Desnoyers wrote:
On 2023-10-25 10:31, Steven Rostedt wrote:
On Wed, 25 Oct 2023 15:55:45 +0200
Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
No, I wouldn't say it's the same as priority inheritance, which is to help
with determinism and not performance. PI adds overhead but removes
unbounded latency. On average, a non PI mutex is faster than PI mutex, but
can suffer from unbounded priority inversion.
Hopefully I'm not oversimplifying if I state that we have mainly two
actors to consider:
[A] the lock owner thread
[B] threads that block trying to acquire the lock
The fast-path here is [A]. [B] can go through a system call, I don't
think it matters at all.
No, B going into a system call can be just as devastating. Adaptive
spinning helps with that. The thing here is that if A gets preempted, there
will be a lot more B's getting stuck.
I implemented the test with futexes (where you go to sleep on contention)
and the performance dropped considerably, where the benefits of not having
A get preempted made no difference at all. Sure, adaptive spinning helps in
that case, but adaptive spinning would only make it as good as my spinning
in user space logic is without any changes.
Those lock addresses could then be used as keys for private locks,
or transformed into inode/offset keys for shared-memory locks. Threads
[B] blocking trying to acquire the lock can call a system call which
would boost the lock owner's slice and/or priority for a given lock key.
Do you mean that this would be done in user space? Going into the kernel to
do any of this would make it already lost.
When the scheduler preempts [A], it would check whether the rseq
per-thread area has a "held locks" field set and use this information
to find the slice/priority boost which are currently active for each
lock, and use this information to boost the task slice/priority
accordingly.
Why do we care about locks here? Note, I'm looking at using this same
feature for VMs on interrupt handlers. The only thing user space needs to
tell the kernel is "It's not a good time to preempt me, but it will be
shortly".
A scheme like this should allow lock priority inheritance without
requiring system calls on the userspace lock/unlock fast path.
Priority inheritance doesn't make sense when everything is running.