Messages in this thread | | | Date | Mon, 13 Mar 2000 15:02:34 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
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/
| |