Re: RT task scheduling

From: Bill Huey (hui) <billh@gnuppy.monkey.org>
To: Darren Hart <darren@dvhart.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Stultz, John" <johnstul@us.ibm.com>,
	Peter Williams <pwil3058@bigpond.net.au>,
	"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	"Bill Huey (hui)" <billh@gnuppy.monkey.org>
Subject: Re: RT task scheduling
Date: Fri, 7 Apr 2006 02:23:59 -0700	[thread overview]
Message-ID: <20060407092359.GB11706@gnuppy.monkey.org> (raw)
In-Reply-To: <200604052025.05679.darren@dvhart.com>

On Wed, Apr 05, 2006 at 08:25:04PM -0700, Darren Hart wrote:
> Part of the issue here is to define what we consider "correct behavior" for 
> SCHED_FIFO realtime tasks.  Do we (A) need to strive for "strict realtime 
> priority scheduling" where the NR_CPUS highest priority runnable SCHED_FIFO 
> tasks are _always_ running?  Or do we (B) take the best effort approach with 
> an upper limit RT priority imbalances, where an imbalance may occur (say at 
> wakeup or exit) but will be remedied within 1 tick.  The smpnice patches 
> improve load balancing, but don't provide (A).

I regret getting into this discussion late, but it should always be (A)
if you're building a kernel for strict RT usage. (B) is for a system that's
more general purpose. It's not a "one policy fits all" kind of problem.

The search costs of (A) could be be significant and may degrade system
performance. Optimizations for that case is for another discussion.

bill