Re: arch maintainers: RFC on spinlock refactoring

[Torvald Riegel <triegel at redhat dot com>]

On Mon, 2017-02-20 at 15:34 -0500, Carlos O'Donell wrote:
> On 02/18/2017 01:23 PM, Torvald Riegel wrote:
> > We want to refactor the spinlock code (ie, pthread_spin* functions); the
> > goal is to improve the generic implementation and use it for as many
> > architectures as possible.  Stefan Liebler has started this work on the
> > s390 side.
> > 
> > I'd like to have input on some arch-specific questions from some of you.
> > 
> > Roughly, I think we should
> > * Finish Stefan's first patch that brings the generic spinlock code into
> > a good shape.
> > * Add some properties of atomic operations to each arch's
> > atomic-machine.h; for now, we're considering 1) whether atomic
> > read-modify-writes are implemented through CAS and 2) whether a CAS
> > always brings in the cache line in an exclusive state (ie, even when the
> > CAS would fail).
> 
> OK.
> 
> > * Move as many architectures as we can without detailed review to the
> > generic spinlock.
> > * Integrate the spinlock code of the remaining archs; this may require
> > either extending the generic spinlock code (eg, if the arch comes with
> > more advanced spinning) or improving the atomics of those archs.
> > * Improve the back-off strategy; use microbenchmarks to justify changes.
> 
> OK.
> 
> > archs that should be able to simply use the generic spinlock after
> > Stefan's first patch has been applied:
> > aarch64, microblaze, arm, m68k, s390, mips, nios2
> 
> > hppa:
> > * I suppose we can use generic once we've fixed the atomics (ie, make
> > atomic stores use the kernel atomics emulation too)?
> 
> Yes. My outstanding question is about pthread_spin_init() and the current
> hppa implementation which uses atomic_exchange_rel (lock, 0) because it is
> required to ensure the kernel helper is used and to ensure a true happens-before.

OK.  So I'd just leave it to you to remove the custom spinlock code
(assuming that we get around to changing the spinlock earlier than we
get to fix the hppa atomics ;) ...).

> The nptl generic implementation just has *lock = 0.

Yes, Stefan's patch changes this to a atomic_store_release.