On Sat, Mar 24, 2007 at 06:29:59PM +0100, Ingo Molnar wrote: > > * Nikita Danilov <[EMAIL PROTECTED]> wrote: > > > Indeed, this technique is very well known. E.g., > > http://citeseer.ist.psu.edu/anderson01sharedmemory.html has a whole > > section (3. Local-spin Algorithms) on them, citing papers from the > > 1990 onward. > > that is a cool reference! So i'd suggest to do (redo?) the patch based > on those concepts and that terminology and not use 'queued spinlocks' > that are commonly associated with MS's stuff. And as a result the > contended case would be optimized some more via local-spin algorithms. > (which is not a key thing for us, but which would be nice to have > nevertheless)
Firstly, the terminology in that paper _is_ "queue lock", which isn't really surprising. I don't really know or care about what MS calls their locks, but I'd suggest that their queued spinlock is probably named in reference to its queueing property rather than its local spin property. Mine is a queueing lock, so I'll continue to call it queued spinlocks (not that the terminology will make it into our API anyway, because I intend for them simply to be an implementation of spinlocks). Secondly, as you say, local spin isn't really a must have. If SGI hasn't made a big stink about them by now, then I think queued locks (which are addressing a real hardware starvation issue on opterons) is more important. That isn't to say that local spin might not help performance, or that my queued spinlocks would make it impossible to implement... it's just that it isn't my aim. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
