From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 29 Apr 2008 10:50:30 -0500 From: Robin Holt Subject: Re: [PATCH 01 of 12] Core of mmu notifiers 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> <20080429001052.GA8315@duo.random> <20080429153052.GE8315@duo.random> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080429153052.GE8315@duo.random> Sender: owner-linux-mm@kvack.org Return-Path: To: Andrea Arcangeli Cc: Christoph Lameter , Robin Holt , 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 , akpm@linux-foundation.org, Rusty Russell List-ID: > 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 -- 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: email@kvack.org