Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 8 May 2011 10:55:02 -0400
From:      Attilio Rao <attilio@freebsd.org>
To:        Nathan Whitehorn <nwhitehorn@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:  <BANLkTi=6N_bjB2Mf5wffXRRscbAT4%2BMcGQ@mail.gmail.com>
In-Reply-To: <4DC6AE27.3060803@freebsd.org>
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> <4DC6AE27.3060803@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
2011/5/8 Nathan Whitehorn <nwhitehorn@freebsd.org>:
> 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:
>>>>>> =C2=A0All architectures define the size-bounded types (uint32_t, uin=
t64_t,
>>>>>> etc.)
>>>>>> =C2=A0starting from base C types (int, long, etc).
>>>>>> =C2=A0That is also reflected when building atomic operations, as the
>>>>>> =C2=A0size-bounded types are built from the base C types.
>>>>>>
>>>>>> =C2=A0However, 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.
>>>>>
>>>>>> =C2=A0bugs.
>>>>>> =C2=A0Cleanup the atomic implementation by defining as base the base=
 C type
>>>>>> =C2=A0version and depending on them, appropriately.
>>>>>
>>>>> I think that it is mostly the other arches that are backwards here,
>>>>> except for plain ints. =C2=A0MI code cannot use atomic ops for anythi=
ng
>>>>> except plain ints, since no other type is guaranteed to be supported
>>>>> by the MD code. =C2=A0For 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 suppor=
t
>>>>> 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 PP=
C,
>>> making them undefined. Since long is also a 32-bit type like int on the=
se
>>> 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.

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).

Attilio


--=20
Peace can only be achieved by understanding - A. Einstein



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=6N_bjB2Mf5wffXRRscbAT4%2BMcGQ>