lkml.org 
[lkml]   [1999]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.107 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site