From mboxrd@z Thu Jan  1 00:00:00 1970
From: Robin Holt <holt@sgi.com>
Subject: [ofa-general] Re: [PATCH 01 of 12] Core of mmu notifiers
Date: Tue, 29 Apr 2008 10:50:30 -0500
Message-ID: <20080429155030.GB28944@sgi.com>
References: <20080424064753.GH24536@duo.random>
	<20080424095112.GC30298@sgi.com>
	<20080424153943.GJ24536@duo.random>
	<20080424174145.GM24536@duo.random>
	<20080426131734.GB19717@sgi.com> <20080427122727.GO9514@duo.random>
	<Pine.LNX.4.64.0804281332030.31163@schroedinger.engr.sgi.com>
	<20080429001052.GA8315@duo.random>
	<Pine.LNX.4.64.0804281819020.2502@schroedinger.engr.sgi.com>
	<20080429153052.GE8315@duo.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Nick Piggin <npiggin@suse.de>, Rusty Russell <rusty@rustcorp.com.au>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>, kvm-devel@lists.sourceforge.net,
	Kanoj Sarcar <kanojsarcar@yahoo.com>, Roland Dreier <rdreier@cisco.com>,
	Jack Steiner <steiner@sgi.com>, linux-kernel@vger.kernel.org,
	Avi Kivity <avi@qumranet.com>, linux-mm@kvack.org,
	Robin Holt <holt@sgi.com>, general@lists.openfabrics.org,
	Hugh Dickins <hugh@veritas.com>, akpm@linux-foundation.org,
	Christoph Lameter <clameter@sgi.com>
To: Andrea Arcangeli <andrea@qumranet.com>
Return-path: <general-bounces@lists.openfabrics.org>
Content-Disposition: inline
In-Reply-To: <20080429153052.GE8315@duo.random>
List-Unsubscribe: <http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general>,
	<mailto:general-request@lists.openfabrics.org?subject=unsubscribe>
List-Archive: <http://lists.openfabrics.org/pipermail/general>
List-Post: <mailto:general@lists.openfabrics.org>
List-Help: <mailto:general-request@lists.openfabrics.org?subject=help>
List-Subscribe: <http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general>,
	<mailto:general-request@lists.openfabrics.org?subject=subscribe>
Sender: general-bounces@lists.openfabrics.org
Errors-To: general-bounces@lists.openfabrics.org
List-Id: kvm.vger.kernel.org

> I however doubt this will bring us back to the same performance of the
> current spinlock version, as the real overhead should come out of
> overscheduling in down_write ai anon_vma_link. Here an initially
> spinning lock would help but that's gray area, it greatly depends on
> timings, and on very large systems where a cacheline wait with many
> cpus forking at the same time takes more than scheduling a semaphore
> may not slowdown performance that much. So I think the only way is a
> configuration option to switch the locking at compile time, then XPMEM
> will depend on that option to be on, I don't see a big deal and this
> guarantees embedded isn't screwed up by totally unnecessary locks on UP.

You have said this continually about a CONFIG option.  I am unsure how
that could be achieved.  Could you provide a patch?

Thanks,
Robin