From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757497AbYLPXoZ (ORCPT ); Tue, 16 Dec 2008 18:44:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758946AbYLPXoE (ORCPT ); Tue, 16 Dec 2008 18:44:04 -0500 Received: from mtagate5.uk.ibm.com ([195.212.29.138]:55272 "EHLO mtagate5.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757115AbYLPXoB (ORCPT ); Tue, 16 Dec 2008 18:44:01 -0500 Date: Wed, 17 Dec 2008 00:43:58 +0100 From: Heiko Carstens To: Rusty Russell Cc: David Miller , rostedt@goodmis.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, mathieu.desnoyers@polymtl.ca, paulus@samba.org, benh@kernel.crashing.org, linux-ia64@vger.kernel.org, linux-s390@vger.kernel.org Subject: Re: local_add_return Message-ID: <20081216234358.GC5584@osiris.boeblingen.de.ibm.com> References: <200812161703.00697.rusty@rustcorp.com.au> <20081215.231314.92267481.davem@davemloft.net> <200812170908.05423.rusty@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200812170908.05423.rusty@rustcorp.com.au> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 17, 2008 at 09:08:04AM +1030, Rusty Russell wrote: > On Tuesday 16 December 2008 17:43:14 David Miller wrote: > > Here ya go: > > Very interesting. There's a little noise there (that first local_inc of 243 > is wrong), but the picture is clear: trivalue is the best implementation for > sparc64. > > Note: trivalue uses 3 values, so instead of hitting random values across 8MB > it's across 24MB, and despite the resulting cache damage it's 15% faster. The > cpu_local_inc test is a single value, so no cache effects: it shows trivalue > to be 3 to 3.5 times faster in the cache-hot case. > > This sucks, because it really does mean that there's no one-size-fits-all > implementation of local_t. There's also no platform yet where atomic_long_t > is the right choice; and that's the default! > > Any chance of an IA64 or s390 run? You can normalize if you like, since > it's only to compare the different approaches. atomic_long_t seems to be the right choice on s390. IRQ disable/enable is expensive, but the compare and swap instruction is cheap. I just gave it a quick shot, but please note that there were two hypervisors running below my system (add_return is missing since I used your first patch): atomic_long 19 18 - 3 17 irqsave/rest 57 58 - 39 22 trivalue 43 43 - 4 45 local_t 18 20 - 2 16