Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753291Ab0AGSQN (ORCPT ); Thu, 7 Jan 2010 13:16:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753207Ab0AGSQL (ORCPT ); Thu, 7 Jan 2010 13:16:11 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:60434 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753199Ab0AGSQJ (ORCPT ); Thu, 7 Jan 2010 13:16:09 -0500 Date: Thu, 7 Jan 2010 10:15:31 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain 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 Subject: Re: [RFC][PATCH 6/8] mm: handle_speculative_fault() In-Reply-To: <1262887207.4049.127.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> <1262887207.4049.127.camel@laptop> 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: 1503 Lines: 49 On Thu, 7 Jan 2010, Peter Zijlstra wrote: > > 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. How do you handle the race of fault handler: munmap look up vma without locks .. interrupt happens or something delays things .. remove the vma from the list sync_vma() current->fault_vma = vma etc? Maybe I'm missing something, but quite frankly, the above looks pretty damn fundamental. Something needs to take a lock. If you get rid of the mmap_sem, you need to replace it with another lock. There's no sane way to "look up vma and atomically mark it as busy" without locks. You can do it with extra work, ie something like look up vma without locks current->fault_vma = vma smp_mb(); check that the vma is still on the list (with he appropriate barriers on the munmap side too, of course) where you avoid the lock by basically turning it into an ordering problem, but it ends up being pretty much as expensive anyway for single threads. And for lots and lots of threads, you now made that munmap be pretty expensive. 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/