[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANN689EN66sbBth9PeTSVwwYC9bbyX7QiwT_t+18JB7YRFjw3A@mail.gmail.com>
Date: Tue, 22 Jan 2013 15:17:54 -0800
From: Michel Lespinasse <walken@...gle.com>
To: Rik van Riel <riel@...hat.com>, Ingo Molnar <mingo@...hat.com>,
"Paul E. McKenney" <paulmck@...ibm.com>,
David Howells <dhowells@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Eric Dumazet <edumazet@...gle.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Manfred Spraul <manfred@...orfullife.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/6] fast queue spinlocks
On Tue, Jan 22, 2013 at 3:13 PM, Michel Lespinasse <walken@...gle.com> wrote:
> Additionally I will attach (as a reply to this email) graphs showing total
> spinlock throughput for a microbenchmark consisting of N threads doing
> lock/unlock operations in a tight loop. We can see that the proposed
> fast queue spinlock is comparable to ticket spinlocks for low number
> of threads, scales much better for high number of threads, and is always
> faster than the MCS strawman proposal (which did have the issue of being
> kinda slow at around 2-3 threads).
> mach1 is a 4 socket AMD Barcelona system (16 cores total)
> mach2 is a 2 socket Intel Westmere system (12 cores / 24 threads total)
> mach3 is a 2 socket Intel Sandybridge system (16 cores / 32 threads total)
Graphs are attached (admittedly not the most interesting benchmark).
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
Download attachment "graph.png" of type "image/png" (5128 bytes)
Download attachment "graph.png" of type "image/png" (5029 bytes)
Download attachment "graph.png" of type "image/png" (4740 bytes)
Powered by blists - more mailing lists