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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <48A9B906.7090201@qualcomm.com>
Date:	Mon, 18 Aug 2008 11:01:42 -0700
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
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

Nick Piggin wrote:
> On Monday 18 August 2008 21:51, Peter Zijlstra wrote:
>> On Mon, 2008-08-18 at 21:24 +1000, Nick Piggin wrote:
>>> Really, you think the enterprise distros will willingly break POSIX
>>> and their own backwards compatiblity by default? I wouldn't have
>>> thought so, but anyway I guess they are free to make that choice, so
>>> where's the problem?
>> I'm not seeing why you're making such a big fuss over this - IMO its not
>> such a significant breakage. Esp since very few realtime apps will
>> require such large amounts of time to ever run into the throttle.
>>
>> If their usage is 95%+ cpu they must have magic WCET estamates - or like
>> in this case, be a benchmark app which IMHO just abuses the real-time
>> class.
> 
> Note that this certainly does not have to be the case. It is perfectly
> valid to dynamically scale the work performed according to the amount
> of CPU time available but still be sensitive to latency.
> 
> video decoding would be a really simple example. But you can't just
> "know" how all RT apps are coded and think this is no problem.
> 
> 
>> It's like running your real-time code on a 5% slower cpu - if it runs
>> correctly on the 5% slower cpu, it will run correctly here too.
> 
> Aside from the latency issue which makes this statement incorrect...
> If the code does not run correctly on a 5% slower CPU, it will break.
> How is that OK?
> 
> You might expect many systems would include at least a 5% margin of
> error, but if the kernel takes 5%, then that's 5% of the safety
> margin gone, so while the app might "work", it might no longer
> meet requirements.
> 
> 
>> Note that correctness from a RT pov is making your deadline.
> 
> 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.

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.

Max




--
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/