Re: Remove sparcv8 support

[Carlos O'Donell <carlos at redhat dot com>]

On 10/27/2016 06:52 AM, Torvald Riegel wrote:
> On Wed, 2016-10-26 at 14:47 -0400, David Miller wrote:
>> From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
>> Date: Wed, 26 Oct 2016 16:02:50 -0200
>>
>>>> I am not sure it is as simple as that. Even if the kernel makes sure
>>>> that an emulated CAS is atomic against another emulated CAS, it would
>>>> not guarantee atomicity against a plain store instruction on a different
>>>> CPU, right? For the emulated CAS to work on an SMP system I would think
>>>> the atomic_store_relaxed and atomic_store_release functions would also
>>>> need to be handled by the kernel, locking the write out when the CAS is
>>>> emulated, to keep the interaction linearizable.
>>>>
>>>
>>> I would expect kernel to emulate all the define atomic operation defined
>>> in ISA to provide correct atomic semantic. I am not really sure how
>>> feasible it would be, but the idea is from library standpoint running
>>> on a machine with a emulated atomic provided by kernel is semantic
>>> equal to running on a machine with hardware provided atomic.
>>>
>>> And I think it would be not feasible to keep pushing for C11 atomics
>>> on glibc if we can not guarantee it. 
>>
>> Plain stores would semantically not be allowed on such a shared value
>> anyways.
>>
>> If atomicity is required, then nobody should do direct stores.  Direct
>> stores are unchecked and non-atomic.  Whether the kernel implements
>> the CAS or the cpu does it directly has no bearing on this issue.
>>
>> All entities should always use the CAS operation to modify such values.
> 
> I'm not quite sure what you're trying to say, so I'll make a few general
> comments that will hopefully help clarify.
> 
> It is true that we do want to use the C11 memory model throughout glibc,
> which means a data-race-freedom requirement for glibc code, which in
> turn means having to use atomic operations (ie, atomic_* ()) whenever
> there would be a data race (as defined by C11) otherwise.
> 
> The implementation of atomic_*() in glibc is an exception to that rule,
> in that on some systems we may know that in a controlled environment
> (eg, function not inlined or volatile used), the compiler will generate
> code for a plain store/load in the implementation of an atomic_*()
> function that is equivalent to a relaxed MO atomic store/load (including
> effects of fences).
> This makes concurrent relaxed MO loads/stores work.
> 
> If we also have a non-multi-core system, entering the kernel emulation
> for CAS then stops all other execution on the system, so the CAS
> emulation in the kernel is atomic.
> If instead we have a multi-core system, either the kernel would have to
> temporarily stop all other cores while emulating the CAS, or all
> atomic_*() would have to use the kernel.  Which of these two options is
> better is hard to say upfront.
 
Agreed.

For hppa we have similar problems we I'm moving everything over to
emulated CAS from initialization to accesses e.g. atomic_exchange_*.

-- 
Cheers,
Carlos.