Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934090AbYB2Wl5 (ORCPT ); Fri, 29 Feb 2008 17:41:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760054AbYB2Wlr (ORCPT ); Fri, 29 Feb 2008 17:41:47 -0500 Received: from host36-195-149-62.serverdedicati.aruba.it ([62.149.195.36]:38009 "EHLO mx.cpushare.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756381AbYB2Wlr (ORCPT ); Fri, 29 Feb 2008 17:41:47 -0500 Date: Fri, 29 Feb 2008 23:41:44 +0100 From: Andrea Arcangeli To: Christoph Lameter Cc: Nick Piggin , akpm@linux-foundation.org, Robin Holt , Avi Kivity , Izik Eidus , kvm-devel@lists.sourceforge.net, Peter Zijlstra , general@lists.openfabrics.org, Steve Wise , Roland Dreier , Kanoj Sarcar , steiner@sgi.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, daniel.blueman@quadrics.com Subject: Re: [patch 2/6] mmu_notifier: Callbacks to invalidate address ranges Message-ID: <20080229224144.GE8091@v2.random> References: <20080229005530.GO8091@v2.random> <20080229131302.GT8091@v2.random> <20080229201744.GB8091@v2.random> <20080229212327.GC8091@v2.random> <20080229214800.GD8091@v2.random> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2066 Lines: 51 On Fri, Feb 29, 2008 at 02:12:57PM -0800, Christoph Lameter wrote: > On Fri, 29 Feb 2008, Andrea Arcangeli wrote: > > > > AFAICT The rw semaphore fastpath is similar in performance to a rw > > > spinlock. > > > > read side is taken in the slow path. > > Slowpath meaning VM slowpath or lock slow path? Its seems that the rwsem With slow path I meant the VM. Sorry if that was confusing given locks also have fast paths (no contention) and slow paths (contention). > read side path is pretty efficient: Yes. The assembly doesn't worry me at all. > > pagefault is fast path, VM during swapping is slow path. > > Not sure what you are saying here. A pagefault should be considered as a > fast path and swapping is not performance critical? Yes, swapping is I/O bound and it rarely becomes CPU hog in the common case. There are corner case workloads (including OOM) where swapping can become cpu bound (that's also where rwlock helps). But certainly the speed of fork() and a page fault, is critical for _everyone_, not just a few workloads and setups. > Ok too many calls to schedule() because the slow path (of the semaphore) > is taken? Yes, that's the only possible worry when converting a spinlock to mutex. > But that is only happening for the contended case. Certainly a spinlock is > better for 2p system but the more processors content for the lock (and > the longer the hold off is, typical for the processors with 4p or 8p or > more) the better a semaphore will work. Sure. That's also why the PT lock switches for >4way compiles. Config option helps to keep the VM optimal for everyone. Here it is possible it won't be necessary but I can't be sure given both i_mmap_lock and anon-vma lock are used in some many places. Some TPC comparison would be nice before making a default switch IMHO. -- 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/