SCHED_FIFO and realtime throttling [LWN.net]

SCHED_FIFO and realtime throttling

Posted Sep 5, 2008 9:49 UTC (Fri) by sdalley (subscriber, #18550)
Parent article: SCHED_FIFO and realtime throttling

No realtime programmer worth his or her salt would design software in which the realtime throttling was an issue.

The normal state of a realtime thread is sleeping. Waiting on an event of some sort, a timer, a mutex, a file event, a message/semaphore from an interrupt routine etc. In such a state, the throttle accounting is not kicking in. When the event occurs, the thread is immediately scheduled according to priority, does what it has to, and goes back to sleep.

The realtime thread should absolutely not be busy-waiting in a screaming poll loop or performing compute-bound processing for hundreds of milliseconds at a time. You pass the data to non-realtime tasks for that.

If a well-designed program is running into RT-throttling problems, it's time for a design rethink or a faster processor. IMHO it's quite proper in such cases that the throttling kicks in for the good of the system as a whole.

(Log in to post comments)

SCHED_FIFO and realtime throttling

Posted Sep 10, 2008 1:08 UTC (Wed) by sethml (subscriber, #8471) [Link]

I second this. I've actually written systems using SCHED_FIFO, in which losing a few ms would result in catastrophe. (Not human-killing-robot catastrophe, but you might end up with a bacteria-infested bottle of juice because the system failed to remove a bottle with a damaged cap from the assembly line.) I would totally support the current 95% limit. Any thread running at real-time priority should only be running a small percentage of the time, or else it's screwed. Having the 95% limit would have saved me many hours - instead I'd have to power-cycle the system, since there was no way to kill the rogue thread. (And for reasons I never figured out, setting up an sshd at an even higher SCHED_FIFO priority didn't work.)

What I would have killed for at the time was a real-time scheduler for which I could specify much more complex constraints. I'd have loved to be able to express: thread A gets top priority, but in no more than 100 1ms chunks per second, and thread B gets medium priority, but uses no more than 90% of the CPU available to it, and thread C gets whatever's left. (Thread C would be my communications thread, so that the controller of the system could actually fix it if something went wrong.)