From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 1 Feb 2005 10:44:25 -0800 (PST) From: Christoph Lameter Subject: Re: page fault scalability patch V16 [3/4]: Drop page_table_lock in handle_mm_fault In-Reply-To: <41FF0281.6090903@yahoo.com.au> Message-ID: References: <41E5B7AD.40304@yahoo.com.au> <41E5BC60.3090309@yahoo.com.au> <20050113031807.GA97340@muc.de> <20050113180205.GA17600@muc.de> <20050114043944.GB41559@muc.de> <20050114170140.GB4634@muc.de> <41FF0281.6090903@yahoo.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Andi Kleen , Andrew Morton , torvalds@osdl.org, hugh@veritas.com, linux-mm@kvack.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, benh@kernel.crashing.org List-ID: On Tue, 1 Feb 2005, Nick Piggin wrote: > Hmm, this is moving toward the direction my patches take. You are right. But I am still weary of the transactional idea in your patchset (which is really not comparable with a database transaction after all...). I think moving to cmpxchg and xchg operations will give this more transparency and make it easier to understand and handle. > Naturally I prefer the complete replacement that is made with > my patch - however this of course means one has to move > *everything* over to be pte_cmpxchg safe, which runs against > your goal of getting the low hanging fruit with as little fuss > as possible for the moment. I would also prefer a replacement but there are certain cost-benefit tradeoffs with atomic operations vs. spinlock that may better be tackled on a case by case basis. Also this is pretty much at the core of the Linux VM and thus highly sensitive. Given its history and the danger of breaking things it may be best to preserve it intact as much as possible and move in small steps. -- 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: aart@kvack.org