svn commit: r221614 - projects/largeSMP/sys/powerpc/include

[Nathan Whitehorn]

On 05/08/11 09:49, Attilio Rao wrote:
> 2011/5/8 Nathan Whitehorn<nwhitehorn at freebsd.org>:
>> On 05/08/11 09:44, Attilio Rao wrote:
>>>
>>> 2011/5/8 Bruce Evans<brde at 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