On Mon, 13 Mar 2000, Jamie Lokier wrote:
>
> You have to do them together. Just resched on irq won't give low
> latency when you get an irq in a spinlock region.
"perfect is the enemy of good".
This adds complexity and makes the normal case slower.
I'm already concerned about doing a single (nonatomic and completely
parallell as far as the CPU is concerned) inc/dec for each spinlock
operation. Adding conditional jumps to the mix makes it worse.
> 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.
The synchronous wake-up is an example of why we do NOT want to do your and
Ingo's "perfect" case. It becomes nasty as hell.
In contrast, the simple inc/dec without being clever and looking for
pending schedules gets the above case right too. Not by magic, but just by
being simple. We'll re-schedule at the proper time later on, which is what
we want to do anyway.
Sure, once in a blue moon we might be unlucky, and have a pending
reschedule for longer than we want. Big deal, especially as we've never
claimed to be hard-RT anyway.
Linus
-
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:28 EST