| |||||||||||||
SCHED_FIFO and realtime throttlingSCHED_FIFO and realtime throttlingPosted Sep 10, 2008 1:08 UTC (Wed) by sethml (subscriber, #8471)In reply to: SCHED_FIFO and realtime throttling by sdalley Parent article: SCHED_FIFO and realtime throttling 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.)
(Log in to post comments)
|
|||||||||||||