linux-kernel - Re: [rfc][patch] queued spinlocks (i386)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Mar 2007 08:43:18 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Nikita Danilov <nikita@...sterfs.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ravikiran G Thirumalai <kiran@...lex86.org>
Subject: Re: [rfc][patch] queued spinlocks (i386)

On Sat, Mar 24, 2007 at 06:29:59PM +0100, Ingo Molnar wrote:
> 
> * Nikita Danilov <nikita@...sterfs.com> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/