From: Stefani Seibold <stefani@seibold.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com
Subject: Re: SCHED_FIFO and SCHED_RR broken by cfs
Date: Sat, 16 Aug 2008 23:29:50 +0200 [thread overview]
Message-ID: <1218922190.3747.6.camel@matrix> (raw)
In-Reply-To: <1218898413.10800.252.camel@twins>
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.
>
>
>
next prev parent reply other threads:[~2008-08-16 21:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-16 9:55 SCHED_FIFO and SCHED_RR broken by cfs Stefani Seibold
2008-08-16 14:53 ` Peter Zijlstra
2008-08-16 16:26 ` Stefani Seibold
2008-08-16 21:29 ` Stefani Seibold [this message]
2008-08-17 22:15 ` Dario Faggioli
2008-08-18 10:47 ` [PATCH] sched: rt-bandwidth disable fixes Peter Zijlstra
2008-08-18 11:11 ` Peter Zijlstra
2008-08-17 13:04 ` SCHED_FIFO and SCHED_RR broken by cfs Nick Piggin
2008-08-18 10:50 ` Peter Zijlstra
2008-08-18 10:58 ` Nick Piggin
2008-08-18 11:09 ` Peter Zijlstra
2008-08-18 11:24 ` Nick Piggin
2008-08-18 11:51 ` Peter Zijlstra
2008-08-18 12:14 ` Nick Piggin
2008-08-18 18:01 ` Max Krasnyansky
2008-08-18 19:46 ` Peter Zijlstra
2008-08-19 7:44 ` Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1218922190.3747.6.camel@matrix \
--to=stefani@seibold.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).