lkml.org 
[lkml]   [2004]   [Oct]   [9]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 9 Oct 2004 12:46:00 +0200
FromIngo Molnar <>
SubjectRe: voluntary-preempt-2.6.9-rc3-mm3-T3
* Lee Revell <rlrevell@joe-job.com> wrote:

> > > With VP and PREEMPT in general, does the scheduler always run the
> > > highest priority process, or do we only preempt if a SCHED_FIFO process
> > > is runnable?
> > 
> > Always the highest priority runnable.
> > 
> 
> Hmm, interesting.  Would there be any advantage to a mode where only
> SCHED_FIFO tasks can preempt?  This seems like a much lighter way to
> solve the realtime problem.

it could be done, but i dont think we should do it. It makes RT
scheduling much more of a special-case. Right now RT scheduling is 99%
like normal scheduling - with the difference that RT priorities are
"higher" than the normal priorities and that each RT priority level is
"exclusive": the scheduler will let such tasks run until they want,
without applying fairness policies.

by making RT tasks more of a special case we'd destabilize the whole
thing: there would be kernel preemptability bugs that only RT tasks
would hit - resulting in a steady deterioration of PREEMPT support in
the kernel. (the ratio of RT tasks is perhaps 0.1% of all use, or less.) 
So applying _any_ RT-only technique besides the bare minimum is asking
for trouble in the long run.

furthermore, we had hard-to-trigger SMP bugs that the PREEMPT kernel
triggered much faster - resulting in an indirect stabilization of our
SMP code. If nothing else then this alone makes PREEMPT very useful.

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

\
 
 \ /
  Last update: 2005-03-22 14:06    [from the cache]
©2003-2008