[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200808191744.11335.nickpiggin@yahoo.com.au>
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