Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753984Ab0DARKU (ORCPT ); Thu, 1 Apr 2010 13:10:20 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:40894 "EHLO e4.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751117Ab0DARKM (ORCPT ); Thu, 1 Apr 2010 13:10:12 -0400 Message-ID: <4BB4D36A.5080204@us.ibm.com> Date: Thu, 01 Apr 2010 10:10:02 -0700 From: Darren Hart User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Avi Kivity CC: "lkml, " , Steven Rostedt , Peter Zijlstra , Gregory Haskins , Sven-Thorsten Dietrich , Peter Morreale , Chris Wright , Thomas Gleixner , Ingo Molnar , Eric Dumazet , Chris Mason Subject: Re: RFC: Ideal Adaptive Spinning Conditions References: <4BB3D90C.3030108@us.ibm.com> <4BB4ABBB.4000909@redhat.com> <4BB4C1C4.2090208@us.ibm.com> <4BB4C566.8060308@redhat.com> In-Reply-To: <4BB4C566.8060308@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2025 Lines: 58 Avi Kivity wrote: > On 04/01/2010 06:54 PM, Darren Hart wrote: >>> A lock(); unlock(); loop spends most of its time with the lock held >>> or contended. Can you something like this: >>> >>> >>> lock(); >>> for (i = 0; i < 1000; ++i) >>> asm volatile ("" : : : "memory"); >>> unlock(); >>> for (i = 0; i < 10000; ++i) >>> asm volatile ("" : : : "memory"); >> >> >> >> Great idea. I'll be doing a more rigorous investigation on this of >> course, but I thought I'd share the results of just dumping this into >> the testcase: >> >> # ./futex_lock -i10000000 >> futex_lock: Measure FUTEX_LOCK operations per second >> Arguments: iterations=10000000 threads=256 adaptive=0 >> Result: 420 Kiter/s >> lock calls: 9999872 >> lock syscalls: 665824 (6.66%) >> unlock calls: 9999872 >> unlock syscalls: 861240 (8.61%) >> >> # ./futex_lock -a -i10000000 >> futex_lock: Measure FUTEX_LOCK operations per second >> Arguments: iterations=10000000 threads=256 adaptive=1 >> Result: 426 Kiter/s >> lock calls: 9999872 >> lock syscalls: 558787 (5.59%) >> unlock calls: 9999872 >> unlock syscalls: 603412 (6.03%) >> >> This is the first time I've seen adaptive locking have an advantage! >> The second set of runs showed a slightly greater advantage. Note that >> this was still with spinners being limited to one. > > Question - do all threads finish at the same time, or wildly different > times? I'm not sure, I can add some fairness metrics to the test that will help characterize how that's working. My suspicion is that there will be several threads that don't make any progress until the very end - since adaptive spinning is an "unfair" locking technique. -- Darren Hart IBM Linux Technology Center Real-Time Linux Team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/