| |||||||||||||
SCHED_FIFO and realtime throttlingSCHED_FIFO and realtime throttlingPosted Sep 3, 2008 2:32 UTC (Wed) by walken (subscriber, #7089)In reply to: SCHED_FIFO and realtime throttling by nix Parent article: SCHED_FIFO and realtime throttling
> (What's the difference between a process taking most of the CPU and one
> taking all of it on a slightly slower machine? A process, realtime or not, > that cares that it's running 5% slower than otherwise is a broken process > --- just like one that hogs the CPU constantly for ten seconds and doesn't > let anyone else get a word in edgeways.)
The process running 100% of the time on a slow machine will see time progress in small increments (say, if it calls gettimeofday in a loop, it'll see it progress a few microseconds at a time) while the process running 95% on a fast machine will see a large time increment once in a while, when it is descheduled. So, there definitely is a difference, for realtime processes.
Still, I do not understand why one would try to yank 100% of the CPU on a posix system and expect the underlying OS to work fine...
(Log in to post comments)
SCHED_FIFO and realtime throttling Posted Sep 4, 2008 11:24 UTC (Thu) by mb (subscriber, #50428) [Link]
Yeah well, a hard (old style) RT process will also be interrupted once in a while by hardware interrupts. Sure, the time running an IRQ is a lot lower than the time a process is scheduled away, but still.
If you really care about not getting interrupted at all, you should be running inside of the kernel or probably with rtai or rtlinux.
SCHED_FIFO and realtime throttling Posted Sep 5, 2008 10:27 UTC (Fri) by dmarkh (guest, #40670) [Link]
The thing is anyone actually having a dedicated machine to run that (old style) RT process is almost surely running on an SMP machine and has isolated his CPU from hardware interrupts and other processes. But even doing that, the kernel thinks that IT owns the CPUs in your box, not you, and requires some time on YOUR cpu regardless of your requirements. Folks, the kernel is just plain broken when you have 4 processors and cannot dedicate %100 of a single processor for a RT application. When you run a process at %100 on a single processor it breaks the kernel because the kernel can't get the processor for it's workque and other crap it thinks it needs to run on YOUR cpu. I think all this throttling crap is more of a "Lets not let userland break our kernel" sort of thing rather than "Lets not let user land break them selves" sort of thing.
I will admit though, for a non SMP box this is probably a good thing as a default setting.
|
|||||||||||||