User: Password:
Subscribe / Log in / New account

The realtime preemption endgame

The realtime preemption endgame

Posted Aug 5, 2009 18:49 UTC (Wed) by PaulMcKenney (subscriber, #9624)
In reply to: The realtime preemption endgame by tertium
Parent article: The realtime preemption endgame

I would argue that replacing spinlocks with mutexes would make things like adaptive mutexes more urgently needed.

(Log in to post comments)

The realtime preemption endgame

Posted Aug 5, 2009 19:09 UTC (Wed) by tertium (subscriber, #56169) [Link]

I just don't see how the two will co-exist. In an rt-kernel, spinlocks are being replaced with mutexes so that a thread waiting for a lock could be preempted. And with adaptive mutexes, a thread entering a mutex will (in certain circumstances) spin, thus breaking the latency guarantees, if I read the article well. Could you please shed some light on this?

The realtime preemption endgame

Posted Aug 5, 2009 20:39 UTC (Wed) by PaulMcKenney (subscriber, #9624) [Link]

Just to make sure I understand, your concern is exemplified by the following sequence of events, right?
  1. High-priority task A is initially blocked waiting for something to do.
  2. Low-priority task B acquires a lock.
  3. Medium-priority tasks C, D, E, and so on (one per CPU) start running, preempting task B.
  4. Work arrives for task A, so that it wakes up, preempting one of the medium-priority tasks.
  5. Task A now attempts to acquire the lock held by preempted task B, and spins for awhile (uselessly degrading latency).
  6. 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 (subscriber, #56169) [Link]

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 (subscriber, #9624) [Link]

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 (subscriber, #56169) [Link]

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 (subscriber, #56169) [Link]

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 (subscriber, #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.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds