Date: Sun, 08 May 2011 09:52:23 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Attilio Rao <attilio@freebsd.org> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include Message-ID: <4DC6AE27.3060803@freebsd.org> In-Reply-To: <BANLkTinD78M6zK6Sjpr_VROe-cJpAZbHzQ@mail.gmail.com> References: <201105080039.p480doiZ021493@svn.freebsd.org> <20110508202725.K1192@besplex.bde.org> <BANLkTim_kNZJZxVe1%2BWFPjL5-4oVUORo1Q@mail.gmail.com> <4DC6ACE6.2090609@freebsd.org> <BANLkTinD78M6zK6Sjpr_VROe-cJpAZbHzQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/08/11 09:49, Attilio Rao wrote: > 2011/5/8 Nathan Whitehorn<nwhitehorn@freebsd.org>: >> On 05/08/11 09:44, Attilio Rao wrote: >>> >>> 2011/5/8 Bruce Evans<brde@optusnet.com.au>: >>>> >>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DC6AE27.3060803>