Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755314Ab0AES53 (ORCPT ); Tue, 5 Jan 2010 13:57:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752617Ab0AES52 (ORCPT ); Tue, 5 Jan 2010 13:57:28 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:45555 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754057Ab0AES52 (ORCPT ); Tue, 5 Jan 2010 13:57:28 -0500 Date: Tue, 5 Jan 2010 10:56:37 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Christoph Lameter cc: Andi Kleen , KAMEZAWA Hiroyuki , Minchan Kim , Peter Zijlstra , "Paul E. McKenney" , Peter Zijlstra , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hugh.dickins" , Nick Piggin , Ingo Molnar Subject: Re: [RFC][PATCH 6/8] mm: handle_speculative_fault() In-Reply-To: Message-ID: References: <20100104182429.833180340@chello.nl> <20100104182813.753545361@chello.nl> <20100105092559.1de8b613.kamezawa.hiroyu@jp.fujitsu.com> <28c262361001042029w4b95f226lf54a3ed6a4291a3b@mail.gmail.com> <20100105134357.4bfb4951.kamezawa.hiroyu@jp.fujitsu.com> <20100105143046.73938ea2.kamezawa.hiroyu@jp.fujitsu.com> <20100105163939.a3f146fb.kamezawa.hiroyu@jp.fujitsu.com> <87wrzwbh0z.fsf@basil.nowhere.org> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1411 Lines: 34 On Tue, 5 Jan 2010, Christoph Lameter wrote: > > There will not be much spinning. The cacheline will be held exclusively by > one processor. A request by other processors for shared access to the > cacheline will effectively stop the execution on those processors until > the cacheline is available. AT WHICH POINT THEY ALL RACE TO GET IT TO SHARED MODE, only to then have one of them actually see that it got a ticket! Don't you see the problem? The spinlock (with ticket locks) essentially does the "xadd" atomic increment anyway, but then it _waits_ for it. All totally pointless, and all just making for problems, and wasting CPU time and causing more cross-node traffic. In contrast, a native xadd-based rwsem will basically do the atomic increment (that ticket spinlocks also do) and then just go on with its life. Never waiting for all the other CPU's to also do their ticket spinlocks. The "short critical region" you talk about is totally meaningless, since the contention will mean that everybody is waiting and hitting that cacheline for a long time regardless - they'll be waiting for O(n) _other_ CPU's to get the lock first! Linus -- 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/