Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750967Ab0AEFLN (ORCPT ); Tue, 5 Jan 2010 00:11:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750773Ab0AEFLM (ORCPT ); Tue, 5 Jan 2010 00:11:12 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:34226 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750734Ab0AEFLL (ORCPT ); Tue, 5 Jan 2010 00:11:11 -0500 Date: Mon, 4 Jan 2010 21:10:29 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: KAMEZAWA Hiroyuki cc: Minchan Kim , Peter Zijlstra , "Paul E. McKenney" , Peter Zijlstra , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , cl@linux-foundation.org, "hugh.dickins" , Nick Piggin , Ingo Molnar Subject: Re: [RFC][PATCH 6/8] mm: handle_speculative_fault() In-Reply-To: <20100105134357.4bfb4951.kamezawa.hiroyu@jp.fujitsu.com> 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> 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: 1330 Lines: 31 On Tue, 5 Jan 2010, KAMEZAWA Hiroyuki wrote: > > Then, my patch dropped speculative trial of page fault and did synchronous > job here. I'm still considering how to insert some barrier to delay calling > remove_vma() until all page fault goes. One idea was reference count but > it was said not-enough crazy. What lock would you use to protect the vma lookup (in order to then increase the refcount)? A sequence lock with RCU lookup of the vma? Sounds doable. But it also sounds way more expensive than the current VM fault handling, which is pretty close to optimal for single-threaded cases.. That RCU lookup might be cheap, but just the refcount is generally going to be as expensive as a lock. Are there some particular mappings that people care about more than others? If we limit the speculative lookup purely to anonymous memory, that might simplify the problem space? [ From past experiences, I suspect DB people would be upset and really want it for the general file mapping case.. But maybe the main usage scenario is something else this time? ] 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/