linux-kernel - Re: SCHED_FIFO and SCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1218898413.10800.252.camel@twins>
Date:	Sat, 16 Aug 2008 16:53:33 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	linux-kernel@...r.kernel.org, mingo@...hat.com
Subject: Re: SCHED_FIFO and SCHED_RR broken by cfs

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.



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