Andrea Arcangeli wrote:
> Anyway it looks more like your object is to put automatic conditional
> schedules all over the place (when each locks gets dropped) than to take
> advantage of getting rescheduled in kernel mode by an irq.
I think Ingo's idea is to do both: resched on irq when no spinlocks are
held, and if locks are held, resched when the last one is released.
You have to do them together. Just resched on irq won't give low
latency when you get an irq in a spinlock region.
Note: In many cases, spinlock_irqsave doesn't need to do the
spinlock_depth thing on UP. However, not all cases: the code in the
lock region might wake up another task.
enjoy,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:27 EST