Messages in this thread | | | Subject | Re: SCHED_FIFO and SCHED_RR broken by cfs | From | Stefani Seibold <> | Date | Sat, 16 Aug 2008 23:29:50 +0200 |
| |
After disabling kernel support for "Group CPU scheduler" and applying 'echo -1 > /proc/sys/kernel/sched_rt_runtime_us' the behaviour is as expected.
chrt -f 99 ./a.out
average:13 usec min. jitter:0 usec max. jitter:29 usec
chrt -o 0 ./a.out average:153 usec min. jitter:0 usec max. jitter:37035 usec
So the problem is located first in the new sched_rt_runtime_us default value and second in the "Group CPU scheduler".
A last question: I though that the kernel will never break user space. Would it not better to make the old behaviour as the default?
Greetings from Munich/Germany Stefani
Am Samstag, den 16.08.2008, 16:53 +0200 schrieb Peter Zijlstra: > 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. > > >
| |