Messages in this thread | | | Date | Wed, 29 Sep 1999 16:06:59 +0000 | From | Manfred Spraul <> | Subject | Re: possible spinlock optimizations |
| |
Ingo Molnar wrote: > Optimizing/making more complex the slow path impacts > the future development of fast path negatively. The slow path should stay > simple and obvious.
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/
| |