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.)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds