Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2016-11-01 at 12:09 -0400, David Miller wrote:
> From: Torvald Riegel <triegel@redhat.com>
> Date: Tue, 01 Nov 2016 16:59:44 +0100
> 
> > On Tue, 2016-11-01 at 16:07 +0100, Andreas Larsson wrote:
> >> Any comments are most welcome. The spin lock based sparcv8 semaphore
> >> implementation is currently unchanged by this patchset, but I would say
> >> that that should go as well.
> > 
> > Agreed.
> 
> I think tossing out all of the ldstub based v8 code is not wise.
> 
> I was envisioning adding code to use ldstub on v8 when CAS is not
> available in order to maintain the status quo of what worked and
> was functional before the changes which introduced this problem
> for v8 in the first place.
> 
> Having that in place until the kernel-side atomics could be
> implemented, propagated, and supported in glibc would be a nice
> intermediate state compared to what we have now.

How do you intend to make the synchronization primitives work whose
implementation requires a CAS and for which nobody has provided an
alternative implementation that does not require CAS?

Will they remain unsupported?  If so, we're just talking about
semaphores and lowlevellock here.  Barriers, condvars, rwlock would not
be supported anymore.

Would we just not support the process-shared of all these?  If so, it
likely doesn't hurt much to not support process-shared semaphores.

The low-level locks can be changed to just use a TAS instead of a CAS,
which would remove the need to keep the 24b variant just for these.