From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with ESMTP id 9C3B0600580 for ; Thu, 7 Jan 2010 13:00:35 -0500 (EST) Subject: Re: [RFC][PATCH 6/8] mm: handle_speculative_fault() From: Peter Zijlstra In-Reply-To: References: <20100104182429.833180340@chello.nl> <20100104182813.753545361@chello.nl> <20100105054536.44bf8002@infradead.org> <20100105192243.1d6b2213@infradead.org> <1262884960.4049.106.camel@laptop> Content-Type: text/plain; charset="UTF-8" Date: Thu, 07 Jan 2010 19:00:07 +0100 Message-ID: <1262887207.4049.127.camel@laptop> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Linus Torvalds Cc: Christoph Lameter , Arjan van de Ven , "Paul E. McKenney" , KAMEZAWA Hiroyuki , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "minchan.kim@gmail.com" , "hugh.dickins" , Nick Piggin , Ingo Molnar List-ID: On Thu, 2010-01-07 at 09:49 -0800, Linus Torvalds wrote: > > The thing is, I can pretty much _guarantee_ that the speculative page > fault is going to end up doing a lot of nasty stuff that still needs > almost-global locking, and it's likely to be more complicated and slower > for the single-threaded case (you end up needing refcounts, a new "local" > lock or something). Well, with that sync_vma() thing I posted the other day all the speculative page fault needs is a write to current->fault_vma, the ptl and an O(nr_threads) loop on unmap() for file vmas -- aside from writing the pte itself of course. -- 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