From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759261AbYD2Puo (ORCPT ); Tue, 29 Apr 2008 11:50:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756091AbYD2Pud (ORCPT ); Tue, 29 Apr 2008 11:50:33 -0400 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:34312 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753018AbYD2Puc (ORCPT ); Tue, 29 Apr 2008 11:50:32 -0400 Date: Tue, 29 Apr 2008 10:50:30 -0500 From: Robin Holt 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 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> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Holt 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> <20080429001052.GA8315@duo.random> <20080429153052.GE8315@duo.random> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nick Piggin , Rusty Russell , Peter Zijlstra , kvm-devel@lists.sourceforge.net, Kanoj Sarcar , Roland Dreier , Jack Steiner , linux-kernel@vger.kernel.org, Avi Kivity , linux-mm@kvack.org, Robin Holt , general@lists.openfabrics.org, Hugh Dickins , akpm@linux-foundation.org, Christoph Lameter To: Andrea Arcangeli Return-path: Content-Disposition: inline In-Reply-To: <20080429153052.GE8315@duo.random> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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