On Sat, 2008-08-16 at 11:55 +0200, Stefani Seibold wrote:
quoted text
> 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.



--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/