From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758592AbZFNMVm (ORCPT ); Sun, 14 Jun 2009 08:21:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755177AbZFNMVe (ORCPT ); Sun, 14 Jun 2009 08:21:34 -0400 Received: from bilbo.ozlabs.org ([203.10.76.25]:47839 "EHLO bilbo.ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753629AbZFNMVd (ORCPT ); Sun, 14 Jun 2009 08:21:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18996.60235.178618.531664@cargo.ozlabs.ibm.com> Date: Sun, 14 Jun 2009 22:21:31 +1000 From: Paul Mackerras To: Avi Kivity Cc: Linus Torvalds , benh@kernel.crashing.org, akpm@linux-foundation.org, linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation In-Reply-To: <4A34E4A5.3040306@redhat.com> References: <18995.20685.227683.561827@cargo.ozlabs.ibm.com> <4A34E4A5.3040306@redhat.com> X-Mailer: VM 8.0.12 under 22.2.1 (i486-pc-linux-gnu) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Avi Kivity writes: > An alternative implementation using 64-bit cmpxchg will recover most of > the costs of hashed spinlocks. I assume most serious 32-bit > architectures have them? Have a 64-bit cmpxchg, you mean? x86 is the only one I know of, and it already has an atomic64_t implementation using cmpxchg8b (or whatever it's called). My thinking is that the 32-bit non-x86 architectures will be mostly UP, so the overhead is just an interrupt enable/restore. Those that are SMP I would expect to be small SMP -- mostly just 2 cpus and maybe a few 4-way systems. Paul. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id F3835B70E0 for ; Sun, 14 Jun 2009 22:21:35 +1000 (EST) Received: from bilbo.ozlabs.org (bilbo.ozlabs.org [203.10.76.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bilbo.ozlabs.org", Issuer "CAcert Class 3 Root" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id E182CDDD0B for ; Sun, 14 Jun 2009 22:21:35 +1000 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <18996.60235.178618.531664@cargo.ozlabs.ibm.com> Date: Sun, 14 Jun 2009 22:21:31 +1000 From: Paul Mackerras To: Avi Kivity Subject: Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation In-Reply-To: <4A34E4A5.3040306@redhat.com> References: <18995.20685.227683.561827@cargo.ozlabs.ibm.com> <4A34E4A5.3040306@redhat.com> Cc: akpm@linux-foundation.org, Linus Torvalds , linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Avi Kivity writes: > An alternative implementation using 64-bit cmpxchg will recover most of > the costs of hashed spinlocks. I assume most serious 32-bit > architectures have them? Have a 64-bit cmpxchg, you mean? x86 is the only one I know of, and it already has an atomic64_t implementation using cmpxchg8b (or whatever it's called). My thinking is that the 32-bit non-x86 architectures will be mostly UP, so the overhead is just an interrupt enable/restore. Those that are SMP I would expect to be small SMP -- mostly just 2 cpus and maybe a few 4-way systems. Paul.