lkml.org 
[lkml]   [2004]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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    [W:0.239 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site