Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756882AbYFZRsg (ORCPT ); Thu, 26 Jun 2008 13:48:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759317AbYFZRsW (ORCPT ); Thu, 26 Jun 2008 13:48:22 -0400 Received: from viefep20-int.chello.at ([62.179.121.40]:43588 "EHLO viefep20-int.chello.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759254AbYFZRsU (ORCPT ); Thu, 26 Jun 2008 13:48:20 -0400 Subject: Re: Spinlocks: Factor our GENERIC_LOCKBREAK in order to avoid spin with irqs disable From: Peter Zijlstra To: Christoph Lameter Cc: Petr Tesarik , Jeremy Fitzhardinge , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Nick Piggin In-Reply-To: References: <20080507073017.GJ32195@elte.hu> <1214241561.19392.21.camel@elijah.suse.cz> <1214253593.11254.30.camel@twins> <1214254730.11254.34.camel@twins> <48630420.1090102@goop.org> <1214471867.17319.8.camel@elijah.suse.cz> Content-Type: text/plain Date: Thu, 26 Jun 2008 19:48:10 +0200 Message-Id: <1214502490.10371.44.camel@twins.programming.kicks-ass.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 (2.22.2-2.fc9) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1341 Lines: 33 On Thu, 2008-06-26 at 10:02 -0700, Christoph Lameter wrote: > On Thu, 26 Jun 2008, Petr Tesarik wrote: > > > We should probably re-think the whole locking scheme, because spinlocks > > were designed to be held for a short period of time. This was a fair > > assumption when they were introduced, but obviously it is now false in > > many cases (such as virtualization). > > And NUMA. > > > Ticket-based spinlocks have actually already changed the original > > design, so why not implement a generic "lock scheduler" on top of > > spinlock_t and rwlock_t? > > How about making the semaphore / mutex code as fast as spinlocks and just > use that? Hehe, please have a look at a recent -rt tree and possibly test some of that if you're interested. It has adaptive spins for rt_mutex. Which is to say, as long as the lock owner is current on its cpu, we'll spin trying to acquire the lock. The reasoning here is that as long as the owner is running, there is a fair chance it'll release the lock soonish. This is another case where semaphores can never match, due to their lack of ownership. -- 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/