From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756486AbYEHA5k (ORCPT ); Wed, 7 May 2008 20:57:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751367AbYEHA5a (ORCPT ); Wed, 7 May 2008 20:57:30 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:60044 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750929AbYEHA52 (ORCPT ); Wed, 7 May 2008 20:57:28 -0400 Date: Wed, 7 May 2008 17:55:33 -0700 (PDT) From: Linus Torvalds To: Robin Holt cc: Andrea Arcangeli , Andrew Morton , Christoph Lameter , Jack Steiner , Nick Piggin , Peter Zijlstra , kvm-devel@lists.sourceforge.net, Kanoj Sarcar , Roland Dreier , Steve Wise , linux-kernel@vger.kernel.org, Avi Kivity , linux-mm@kvack.org, general@lists.openfabrics.org, Hugh Dickins , Rusty Russell , Anthony Liguori , Chris Wright , Marcelo Tosatti , Eric Dumazet , "Paul E. McKenney" Subject: Re: [PATCH 08 of 11] anon-vma-rwsem In-Reply-To: <20080508003838.GA9878@sgi.com> Message-ID: References: <6b384bb988786aa78ef0.1210170958@duo.random> <20080507212650.GA8276@duo.random> <20080508003838.GA9878@sgi.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) 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 On Wed, 7 May 2008, Robin Holt wrote: > > In order to invalidate the remote page table entries, we need to message > (uses XPC) to the remote side. The remote side needs to acquire the > importing process's mmap_sem and call zap_page_range(). Between the > messaging and the acquiring a sleeping lock, I would argue this will > require sleeping locks in the path prior to the mmu_notifier invalidate_* > callouts(). You simply will *have* to do it without locally holding all the MM spinlocks. Because quite frankly, slowing down all the normal VM stuff for some really esoteric hardware simply isn't acceptable. We just don't do it. So what is it that actually triggers one of these events? The most obvious solution is to just queue the affected pages while holding the spinlocks (perhaps locking them locally), and then handling all the stuff that can block after releasing things. That's how we normally do these things, and it works beautifully, without making everything slower. Sometimes we go to extremes, and actually break the locks are restart (ugh), and it gets ugly, but even that tends to be preferable to using the wrong locking. The thing is, spinlocks really kick ass. Yes, they restrict what you can do within them, but if 99.99% of all work is non-blocking, then the really odd rare blocking case is the one that needs to accomodate, not the rest. Linus