This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
arch maintainers: RFC on spinlock refactoring
- From: Torvald Riegel <triegel at redhat dot com>
- To: GLIBC Devel <libc-alpha at sourceware dot org>
- Cc: Richard Henderson <rth at redhat dot com>, "Carlos O'Donell" <codonell at redhat dot com>, Chris Metcalf <cmetcalf at mellanox dot com>, sjmunroe <sjmunroe at us dot ibm dot com>, David Miller <davem at davemloft dot net>
- Date: Sat, 18 Feb 2017 19:23:45 +0100
- Subject: arch maintainers: RFC on spinlock refactoring
- Authentication-results: sourceware.org; auth=none
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).
* 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.
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
alpha:
* Can we just use plain atomics instead of the custom code?
hppa:
* I suppose we can use generic once we've fixed the atomics (ie, make
atomic stores use the kernel atomics emulation too)?
tile:
* Contains custom back-off implementation. We should discuss this
separately.
* Does CAS always bring in the cache line in exclusive state? I guess
it doesn't?
* I suppose atomic_exchange can't be replaced with atomic_store? Should
this be a flag so that this can be included in the generic code?
* What about trylock? Keep it or use generic?
powerpc:
* I believe we should create versions of the atomic operations that have
MUTEX_HINT_ACQ set. We started to discuss this a while ago, but this
died off. We should pick up this thread again.
x86_64, i386:
* We should move to the generic code. Confirming that there are no
performance regressions would be good. As soon as generic spinlock adds
back-off, generic should perform better under contention.
ia64:
* Move to generic code. Check that the back-off instruction is exposed
through the atomics interface.
sh:
* Use generic spinlock?
sparc:
* sparc64/sparcv9: Use generic spinlock?
* sparc32 pre-v9: ?