From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with ESMTP id 6F1A6600580 for ; Thu, 7 Jan 2010 12:36:49 -0500 (EST) Date: Thu, 7 Jan 2010 09:36:17 -0800 (PST) From: Linus Torvalds Subject: Re: [RFC][PATCH 6/8] mm: handle_speculative_fault() In-Reply-To: <1262884960.4049.106.camel@laptop> Message-ID: References: <20100104182429.833180340@chello.nl> <20100104182813.753545361@chello.nl> <20100105054536.44bf8002@infradead.org> <20100105192243.1d6b2213@infradead.org> <1262884960.4049.106.camel@laptop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Peter Zijlstra 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, 7 Jan 2010, Peter Zijlstra wrote: > > Right, supposing we can make this speculative fault stuff work, then we > can basically reduce the mmap_sem usage in fault to: > > - allocating new page tables > - extending the growable vmas > > And do everything else without holding it, including zeroing and IO. Well, I have yet to hear a realistic scenario of _how_ to do it all speculatively in the first place, at least not without horribly subtle complexity issues. So I'd really rather see how far we can possibly get by just improving mmap_sem. 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