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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 19 Aug 2008 17:44:11 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Max Krasnyansky <maxk@...lcomm.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	"Torvalds, Linus" <torvalds@...ux-foundation.org>,
	Stefani Seibold <stefani@...bold.net>,
	linux-kernel@...r.kernel.org, mingo@...hat.com
Subject: Re: SCHED_FIFO and SCHED_RR broken by cfs

On Tuesday 19 August 2008 04:01, Max Krasnyansky wrote:
> Nick Piggin wrote:
> > On Monday 18 August 2008 21:51, Peter Zijlstra wrote:

> > Correctness from the kernel's POV is implementing APIs as advertised,
> > and just as importantly, not changing them. We can argue about how RT
> > apps work, but there is no argument that the kernel has broken
> > backwards compatibility and standards.
>
> Just wanted to mention that I'm with Nick on this one. I pointed this
> (ie POSIX breakage) out as soon as the change went in. I do have a valid
>   (which some people disagree with ;-)) workload that uses 100% of the
> CPU. So my unit-tests caught this right away.

Ouch. Yep, so much for making assumptions about how apps will use the
API.


> Anyway, "RT bandwidth throttling" has been in and enabled be default
> since 2.6.25. So I'm not sure if it makes sense to revert the default at
> this point.
> If we do change the default maybe we can add a CONFIG_ option for this
> so that it can be compiled out completely.

It definitely does. Most serious users deploying real realtime code
will not be close to 2.6.25. If we leave it until they start complaining,
the problem will be much bigger because then we'll have sets of people
that rely on both behaviours.

Please fix this Peter.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ