Preemption model (was Re: voluntary-preempt-2.6.9-rc3-mm3-T3)

[Lee Revell]

On Sat, 2004-10-09 at 01:34, Con Kolivas wrote:
> Lee Revell 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.
> >>
> >>No, the linux scheduler has always been preemptible. PREEMPT and VP just 
> >>allows it to preempt kernel code paths as well. It could be modified to 
> >>do such a thing but apart from real time applications it would perform 
> >>very badly overall.
> > 
> > 
> > I am talking about a mode where we only allow a SCHED_FIFO process to
> > preempt a kernel code path.  In every other case it works like !PREEMPT.
> > 
> > This is apparently how kernel preemption worked on SVR4.
> 
> Yes it could. If you ask nicely, Ingo might even throw in yet another 
> config option in the kernel. It gets messy if multiple people start 
> hacking on the same thing when it's under heavy development.

Oh, I was not going to post a patch, I don't know the code nearly well
enough at this point :-).  But it looks pretty straightforward.

This also addresses what I think was Linus' main objection to PREEMPT,
which IIRC was (paraphrasing) that maybe if the scheduler had been
smarter we would not be having to preempt all the time.  This argument
is perfectly valid except for a SCHED_FIFO task which by definition will
always know better than the scheduler does when it needs to run.

Lee  

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