linux-kernel - Re: [patch 1/4] x86: FIFO ticket spinlocks

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:	Thu, 1 Nov 2007 09:38:22 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Gregory Haskins <gregory.haskins.ml@...il.com>
cc:	Nick Piggin <npiggin@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andi Kleen <ak@...e.de>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 1/4] x86: FIFO ticket spinlocks

On Thu, 1 Nov 2007, Gregory Haskins wrote:
> 
> I had observed this phenomenon on some 8-ways here as well, but I didn't
> have the bandwidth to code something up.  Thumbs up!

Can you test under interesting loads?

We're interested in:
 - is the unfairness fix really noticeable (or does it just move the 
   problem somewhere else, and there is no real change in behaviour)
 - what is the performance impact?

In particular, unfair spinlocks have the potential to perform much better. 
Not so much because the spinlock itself acts all that differently, but 
because being unfair also fundmanetally tends to keep the data structures 
that are *protected* by the spinlock on just one CPU.

So "unfair" is obviously always bad. Except when it isn't. I'd personally 
like to merge the ticket spinlocks, but I'd really like to have people who 
have real loads where they matter actually also do some performance 
testing. Because I do think it will potentially be a performance downer. 

(I obviously hope it won't be, but..)

		Linus
-
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/