Lee Revell writes:
> On Thu, 2004-10-07 at 06:52, Ingo Molnar wrote:
>> i've released the -T3 VP patch:
>>
>> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc3-mm3-T3
>>
>
> 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.
Cheers,
Con
On Sat, 2004-10-09 at 01:09, Con Kolivas wrote:
> Lee Revell writes:
>
> > On Thu, 2004-10-07 at 06:52, Ingo Molnar wrote:
> >> i've released the -T3 VP patch:
> >>
> >> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc3-mm3-T3
> >>
> >
> > 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.
Lee
Lee Revell wrote:
> On Sat, 2004-10-09 at 01:09, Con Kolivas wrote:
>
>>Lee Revell writes:
>>
>>
>>>On Thu, 2004-10-07 at 06:52, Ingo Molnar wrote:
>>>
>>>>i've released the -T3 VP patch:
>>>>
>>>> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc3-mm3-T3
>>>>
>>>
>>>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.
Con
On Sat, 2004-10-09 at 01:23, Con Kolivas wrote:
> Lee Revell wrote:
> > On Sat, 2004-10-09 at 01:09, Con Kolivas wrote:
> >
> >>Lee Revell writes:
> >>
> >>
> >>>On Thu, 2004-10-07 at 06:52, Ingo Molnar wrote:
> >>>
> >>>>i've released the -T3 VP patch:
> >>>>
> >>>> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc3-mm3-T3
> >>>>
> >>>
> >>>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.
Lee
Lee Revell wrote:
> On Sat, 2004-10-09 at 01:23, Con Kolivas wrote:
>
>>Lee Revell wrote:
>>
>>>On Sat, 2004-10-09 at 01:09, Con Kolivas wrote:
>>>
>>>
>>>>Lee Revell writes:
>>>>
>>>>
>>>>
>>>>>On Thu, 2004-10-07 at 06:52, Ingo Molnar wrote:
>>>>>
>>>>>
>>>>>>i've released the -T3 VP patch:
>>>>>>
>>>>>> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc3-mm3-T3
>>>>>>
>>>>>
>>>>>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.
Cheers,
Con
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
Lee Revell wrote:
> 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.
I was talking about me ;-)
Cheers,
Con
* Lee Revell <[email protected]> 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
Lee Revell wrote:
> On Sat, 2004-10-09 at 01:09, Con Kolivas wrote:
>
>>Lee Revell writes:
>>
>>
>>>On Thu, 2004-10-07 at 06:52, Ingo Molnar wrote:
>>>
>>>>i've released the -T3 VP patch:
>>>>
>>>> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc3-mm3-T3
>>>>
>>>
>>>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.
>
> Lee
>
>
IMHO I don't think this gains us anything and I think that it would be a
big step backward for desktop performance (any processes not scheduled
RT). Not only that but I think you still have to have all of the
overhead of the scheduler and the preemption points if you are going to
service the RT threads. Otherwise, how do you schedule RT processes that
are waiting for some I/O (that is ready) and another non-RT process is
going through a code path in the kernel. The RT process now has a much
worse latency. There very well may be ways to accomplish this
effectively that I just don't understand.
kr