From owner-svn-src-projects@FreeBSD.ORG Sun May 8 15:11:15 2011 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46BCF1065675; Sun, 8 May 2011 15:11:15 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 0B01A8FC0C; Sun, 8 May 2011 15:11:14 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 954D5582C2; Sun, 8 May 2011 09:52:25 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id baswJtNgXG7k; Sun, 8 May 2011 09:52:25 -0500 (CDT) Received: from wanderer.tachypleus.net (unknown [76.210.65.155]) by mail.icecube.wisc.edu (Postfix) with ESMTP id DD3BF582A6; Sun, 8 May 2011 09:52:24 -0500 (CDT) Message-ID: <4DC6AE27.3060803@freebsd.org> Date: Sun, 08 May 2011 09:52:23 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110317 Thunderbird/3.1.9 MIME-Version: 1.0 To: Attilio Rao References: <201105080039.p480doiZ021493@svn.freebsd.org> <20110508202725.K1192@besplex.bde.org> <4DC6ACE6.2090609@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org, Bruce Evans Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 15:11:15 -0000 On 05/08/11 09:49, Attilio Rao wrote: > 2011/5/8 Nathan Whitehorn: >> On 05/08/11 09:44, Attilio Rao wrote: >>> >>> 2011/5/8 Bruce Evans: >>>> >>>> On Sun, 8 May 2011, Attilio Rao wrote: >>>> >>>>> Log: >>>>> All architectures define the size-bounded types (uint32_t, uint64_t, >>>>> etc.) >>>>> starting from base C types (int, long, etc). >>>>> That is also reflected when building atomic operations, as the >>>>> size-bounded types are built from the base C types. >>>>> >>>>> However, powerpc does the inverse thing, leading to a serie of nasty >>>> >>>> I think you mean that it does the inverse thing for atomic ops only. >>>> >>>>> bugs. >>>>> Cleanup the atomic implementation by defining as base the base C type >>>>> version and depending on them, appropriately. >>>> >>>> I think that it is mostly the other arches that are backwards here, >>>> except for plain ints. MI code cannot use atomic ops for anything >>>> except plain ints, since no other type is guaranteed to be supported >>>> by the MD code. For example, sparc64 doesn't support any 8-bit or >>>> 16-bit types, and i386 doesn't support any 64-bit types (until recently; >>>> it now uses cmpxchg8b on some CPUs and a hack on other CPUs to support >>>> 64, bit types), and my version of i386 doesn't support any 8-bit or >>>> 16-bit types or long since these types are unusable in MI code and >>>> unused in MD code (long is misused in some MI code but I don't use >>>> such broken code). >>> >>> I want to comment specifically on this. >>> I think you are right and that over time our kernel policy on atomic >>> has got very flakey. >>> My personal idea is that MI part should support only this: >>> - _int version >>> - _32 bit version >>> - _ptr version >>> >>> and the common sense also mandates it could support easilly: >>> - _long version >> >> One thing I'd like to point out about your patch (which Andreas already >> mentioned) is that it disconnects atomic_*_long operations on 32-bit PPC, >> making them undefined. Since long is also a 32-bit type like int on these >> systems, the 32-bit kernel does in fact support this. >> >>> The following should just be used in specific MD code or be totally >>> unsupported: >>> - _char, _short, _8 bit, _16 bit versions >>> >>> The following should just be used in MD code: >>> - _64 bit version >> >> One other unrelated comment here: ZFS requires 64-bit atomics, so we already >> don't have this situation, sadly. > > I'm wondering how is that supposed to work on 32 bit stuff then. > I really don't want to see 32 bits arch having 64-bits faking atomics > as the only right way to do that is with some sort of interlocking and > that is not really what we want about the concept of 'atomic' (a > lockless and fast primitive). > The answer is that it mostly doesn't. On i386, it uses cmp8xchg. On all other 32-bit systems (ARM/MIPS/PowerPC), it works only with a giant mutex that covers atomic operations. -Nathan