No. Transparent complexity is never a problem - as long as it is 100%
transparent.
> 1) doing a sti and possibly missing the
> just-released spinlock by 7 cycles
> 2) when we _got_ the spinlock we have
> spend another 7 cycles on cli.
I think this is the main problem. I estimate (based on a crude
benchmark) that:
- For "short spinlock operation" (eg changing a linked list), this is a
major disadvantage
- for long-held spinlocks (eg. runqueue lock with huge load-avg's), it
would be a win.
This means:
1) unconditional "sti" in the slow path has no clear speed advantage.
2) it's nearly certain that a "spin_lock_irq_sti()" would improve the
speed, but it violates the transparency.
--> no sti in the slow path.
-- Manfred- 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/