Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755305Ab0AESrh (ORCPT ); Tue, 5 Jan 2010 13:47:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755251Ab0AESrg (ORCPT ); Tue, 5 Jan 2010 13:47:36 -0500 Received: from nlpi157.sbcis.sbc.com ([207.115.36.171]:44422 "EHLO nlpi157.prodigy.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755233Ab0AESrg (ORCPT ); Tue, 5 Jan 2010 13:47:36 -0500 Date: Tue, 5 Jan 2010 12:46:17 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@router.home To: Linus Torvalds 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 (DEB 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: 1417 Lines: 30 On Tue, 5 Jan 2010, Linus Torvalds wrote: > I hope somebody can time it. Because I think the idle reads on all the > (unsuccessful) spinlocks will kill it. > > Think of it this way: under heavy contention, you'll see a lot of people > waiting for the spinlocks and one of them succeeds at writing it, reading > the line. So you get an O(n^2) bus traffic access pattern. In contrast, > with an xadd, you get O(n) behavior - everybody does _one_ acquire-for- > write bus access. 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. Access to main memory is mediated by the cache controller anyways. As long as the cacheline has not been invalidated it will be reused. Maybe Andi can give us more details on the exact behavior on recent Intel processors? One thing that could change with the removal of the spinlock is that the initial request for the cacheline will not be for read anymore but for write. This saves us the upgrade from read / shared state to exclusive access. -- 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/