Messages in this thread |  | | Date | Thu, 04 Jan 2001 22:45:51 -0800 | From | ludovic fernandez <> | Subject | Re: [PATCH] 2.4.0-prerelease: preemptive kernel. |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |