The realtime preemption endgame

Posted Aug 5, 2009 20:39 UTC (Wed) by PaulMcKenney (✭ supporter ✭, #9624)
In reply to: The realtime preemption endgame by tertium
Parent article: The realtime preemption endgame

Just to make sure I understand, your concern is exemplified by the following sequence of events, right?

High-priority task A is initially blocked waiting for something to do.
Low-priority task B acquires a lock.
Medium-priority tasks C, D, E, and so on (one per CPU) start running, preempting task B.
Work arrives for task A, so that it wakes up, preempting one of the medium-priority tasks.
Task A now attempts to acquire the lock held by preempted task B, and spins for awhile (uselessly degrading latency).
Task A finally blocks, which kicks priority inheritance into action, awakening task B, which releases the lock so that task A can acquire it.

Or am I missing your point?

The realtime preemption endgame

Posted Aug 5, 2009 21:21 UTC (Wed) by tertium (guest, #56169) [Link] (5 responses)

I'm imagining a much simpler scenario (for two CPUs):

1. High-priority task A takes a mutex and runs for some time without going to sleep.
2. Low-priority task B tries to take the mutex and spins, since A is running. This is where we lose latency, because...
3. ...while B spins, it can't be preempted, so a medium-priority task C can't run on either of CPUs, even if there is some work for it.

I presume, I'm missing something obvious and would be glad to know what it is.

The realtime preemption endgame

Posted Aug 5, 2009 21:24 UTC (Wed) by PaulMcKenney (✭ supporter ✭, #9624) [Link] (3 responses)

OK, you lost me on this one. Why can't task B be preempted while spinning? What am I missing here?

The realtime preemption endgame

Posted Aug 5, 2009 21:43 UTC (Wed) by tertium (guest, #56169) [Link] (2 responses)

I was actually looking at the following phrase in the article: "Code holding spinlocks also cannot be preempted; doing so would cause serious latencies (at best) or deadlocks." Am I confused?

The realtime preemption endgame

Posted Aug 5, 2009 22:17 UTC (Wed) by tertium (guest, #56169) [Link] (1 responses)

Indeed, it seems I am: "code holding a spinlock" != "code spinning". My apologies.

By the way, in your scenario (if I'm not off the mark again) at the step 5, the task A wouldn't spin, since B isn't running. Instead, A would block immediately, awakening B and taking the lock.

The realtime preemption endgame

Posted Aug 5, 2009 22:47 UTC (Wed) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

Exactly! :-)

The realtime preemption endgame

Posted Aug 7, 2009 15:49 UTC (Fri) by dvhart (guest, #19636) [Link]

It is indeed a balancing act. Testing has shown however that spinning for a short while can be preferable to at least 2 additional context switches (figure 25us or so each). See kernel/rtmutex.c adaptive_wait() for details, but basically we sping until one of the following occurs: we get the lock, the owner changes, or the owner goes to sleep.