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

[Bruce Evans]

On Sun, 8 May 2011, Attilio Rao wrote:

> 2011/5/8 Nathan Whitehorn <nwhitehorn at freebsd.org>:
>> 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:

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