From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754322Ab0AHWsU (ORCPT ); Fri, 8 Jan 2010 17:48:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754251Ab0AHWsU (ORCPT ); Fri, 8 Jan 2010 17:48:20 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:46726 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753520Ab0AHWsT (ORCPT ); Fri, 8 Jan 2010 17:48:19 -0500 Date: Fri, 8 Jan 2010 14:43:02 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Christoph Lameter cc: Peter Zijlstra , KAMEZAWA Hiroyuki , Minchan Kim , "Paul E. McKenney" , "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> <20100106092212.c8766aa8.kamezawa.hiroyu@jp.fujitsu.com> <20100106115233.5621bd5e.kamezawa.hiroyu@jp.fujitsu.com> <20100106125625.b02c1b3a.kamezawa.hiroyu@jp.fujitsu.com> 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 On Fri, 8 Jan 2010, Christoph Lameter wrote: > > And I made the point that starvation was a hardware issue due to immature > cacheline handling. Now the software patchup job for the hardware breakage > is causing regressions for everyone. Well, in all fairness, (a) existing hardware doesn't do a good job, and would have a really hard time doing so in general (ie the whole issue of on-die vs directly-between-sockets vs between-complex-fabric), and (b) in this case, the problem really was that the x86-64 rwsems were badly implemented. The fact that somebody _thought_ that it might be ok to do them with spinlocks and had done some limited testing without ever hitting the problem spot (probably never having tested any amount of contention at all) is immaterial. We should have had real native rwsemaphores for x86-64, and complaining about the fallback sucking under load is kind of pointless. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with ESMTP id 6601B60021B for ; Fri, 8 Jan 2010 17:48:06 -0500 (EST) Date: Fri, 8 Jan 2010 14:43:02 -0800 (PST) From: Linus Torvalds 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> <20100106092212.c8766aa8.kamezawa.hiroyu@jp.fujitsu.com> <20100106115233.5621bd5e.kamezawa.hiroyu@jp.fujitsu.com> <20100106125625.b02c1b3a.kamezawa.hiroyu@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Christoph Lameter Cc: Peter Zijlstra , KAMEZAWA Hiroyuki , Minchan Kim , "Paul E. McKenney" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hugh.dickins" , Nick Piggin , Ingo Molnar List-ID: On Fri, 8 Jan 2010, Christoph Lameter wrote: > > And I made the point that starvation was a hardware issue due to immature > cacheline handling. Now the software patchup job for the hardware breakage > is causing regressions for everyone. Well, in all fairness, (a) existing hardware doesn't do a good job, and would have a really hard time doing so in general (ie the whole issue of on-die vs directly-between-sockets vs between-complex-fabric), and (b) in this case, the problem really was that the x86-64 rwsems were badly implemented. The fact that somebody _thought_ that it might be ok to do them with spinlocks and had done some limited testing without ever hitting the problem spot (probably never having tested any amount of contention at all) is immaterial. We should have had real native rwsemaphores for x86-64, and complaining about the fallback sucking under load is kind of pointless. Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org