george anzinger wrote:
> Roger Larsson wrote:
> >
>
> > This part can probably be put in a proper non inline function.
> > Cache issues...
> > + /*
> > + * At that point a scheduling is healthy iff:
> > + * - a scheduling request is pending.
> > + * - the task is in running state.
> > + * - this is not an interrupt context.
> > + * - local interrupts are enabled.
> > + */
> > + if (current->need_resched == 1 &&
> > + current->state == TASK_RUNNING &&
> > + !in_interrupt() &&
> > + local_irq_are_enabled())
> > + {
> > + schedule();
> > + }
> >
> Actually the MontaVista Patch cleverly removes the tests for
> in_interrupt() and local_irq_are_enabled() AND the state ==
> TASK_RUNNING. In actual fact these states can be considered way points
> on the system status vector. For example the interrupts off state
> implies all the rest, the in_interrupt() implies not preemptable and
> finally, not preemptable is one station away from fully preemptable.
>
> TASK_RUNNING is easily solved by makeing schedule() aware that it is
> being called for preemption. See the MontaVista patch for details.
>
Humm, I'm just curious,
Regarding in_interrupt(). How do you deal with soft interrupts?
Guys calling cpu_bh_disable() or even incrementing the count on
their own. I don't know if this acceptable but definitely can be done,
I prefer to rely on fact than on API.
Regarding local_irq_enabled(). How do you handle the code that
call local_irq_disable(), then spin_lock(), spin_unlock() and only
re-enable the interruptions ? In this case, you preempt code that
is supposed to run interruptions disabled.
Finally, regarding the test on the task state, there may be a cache issue
but calling schedule() has also some overhead.
Ludo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
