Messages in this thread | | | Subject | Re: SCHED_FIFO and SCHED_RR broken by cfs | From | Peter Zijlstra <> | Date | Sat, 16 Aug 2008 16:53:33 +0200 |
| |
On Sat, 2008-08-16 at 11:55 +0200, Stefani Seibold wrote: > Hi kernel hackers, > > it seems that the new completely fair scheduler breaks the SCHED_RR and > SCHED_FIFO realtime scheduler. > > In my opinion a high priority real time user process with SCHED_FIFO > should be only interrupted by the kernel or a process with an higher > priority. So a user process running under SCHED_FIFO and priority 99 > should never be interrupted by any other process. This was true under > kernel 2.6.20. > > On my pentium/celeron III/400 MHz system with kernel 2.6.20 a busy loop > using the "time stamp counter" of the x86 cpu for delaying, this was > very accurate. The max. jitter of the delaying was about 5 microseconds. > > With the new kernel 2.6.26 the jitter is about 51177 microseconds or in > other words 51 milliseconds or more the 10000 times greater than kernel > 2.6.20. This huge latency is far away from realtime. > > Below are the results of the attached test program. Maybe somebody else > can confirm this results. All measurements was done with no other > process running, only the busybox 1.11.1 shell and the init process was > there.
Has nothing to do with CFS, but everything to do with the fact that we now have a 95% bandwidth control by default.
Does doing:
echo -1 > /proc/sys/kernel/sched_rt_runtime_us
fix it?
So, up to 95% cpu usage (per sched_rt_period_us) FIFO and RR behave like they always did, once they cross that line, they'll be throttled.
95% seemed like a sane default in that it leaves a little room to recover from a run-away rt process (esp handy now that !root users can also use RT scheduling classes), and should be enough for most applications as they usually don't consume all that much time.
| |