From owner-svn-src-projects@FreeBSD.ORG Sun May 8 16:25:28 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 969351065676; Sun, 8 May 2011 16:25:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 301D48FC08; Sun, 8 May 2011 16:25:27 +0000 (UTC) Received: from c122-106-155-58.carlnfd1.nsw.optusnet.com.au (c122-106-155-58.carlnfd1.nsw.optusnet.com.au [122.106.155.58]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p48GPP4A013950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 02:25:26 +1000 Date: Mon, 9 May 2011 02:25:25 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Attilio Rao In-Reply-To: Message-ID: <20110509021804.D2381@besplex.bde.org> References: <201105080039.p480doiZ021493@svn.freebsd.org> <20110508202725.K1192@besplex.bde.org> <4DC6ACE6.2090609@freebsd.org> <4DC6AE27.3060803@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org, Nathan Whitehorn , 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 16:25:28 -0000 On Sun, 8 May 2011, Attilio Rao wrote: > 2011/5/8 Nathan Whitehorn : >> On 05/08/11 09:49, Attilio Rao wrote: >>> >>> 2011/5/8 Nathan Whitehorn: >>>> >>>> On 05/08/11 09:44, Attilio Rao wrote: >>>>> 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. I thought that the macro hackery for that was still there (but moved). Otherwise standard kernel files won't compile. >>>>> 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. i386 has only used cmpxchg8b for a few weeks, and only uses it for load/ store. But a non-giant mutex should work OK (just like it does for a data structure much larger than 32 or 64 bits). The mutex has to cover _all_ accesses to the parts of the struct locked by it, which is sometimes not so easy. > This type of code is still ok, I'd say, because it handle platform > size in different ways (it is true it is MI code, but it just uses the > _64 bit operations only for 64 bit architectures, and locking for the > other, if I got it right). Probably much slower for the non-64 arches if it is just hacked on. Bruce