This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Cc: nd at arm dot com, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Siddhesh Poyarekar <siddhesh at sourceware dot org>, Carlos O'Donell <carlos at redhat dot com>
- Date: Fri, 6 Jul 2018 16:25:23 +0100
- Subject: Re: [PATCH 2/2] aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT
- References: <49033e60-fe48-369f-31e0-dc654e18ac40@arm.com>
On 28/06/18 19:25, Szabolcs Nagy wrote:
This enables searching shared libraries in atomics/ when the hardware
supports LSE atomics of armv8.1 so one can provide optimized variants
of libraries in a portable way.
LSE atomics does not affect library abi, the new instructions can
interoperate with old ones.
I considered the earlier comments on the patch
https://sourceware.org/ml/libc-alpha/2018-04/msg00400.html
https://sourceware.org/ml/libc-alpha/2018-04/msg00625.html
It turns out that the way glibc dynamic linker decides on the search
path is not very flexible: it wants to use hwcap bits and associated
strings. So some targets reuse hwcap bits for glibc internal purposes
to affect the search logic. But hwcap is an interface with the kernel,
glibc should not allocate bits in it for its internal logic as that
limits future hwcap extensions and confusing to users who expect to see
hwcap bits in ifunc resolvers. Instead of rewriting the dynamic linker
path logic (which affects all targets) this patch just uses the existing
mechanism, however this means that the path name has to be the hwcap
name "atomics" and cannot be changed to something more meaningful to
users.
It is hard to tell how much performance benefit this can give, in
principle armv8.1 atomics can be better optimized in the hardware, so it
can make a difference for synchronization heavy code. On some systems
such multilib setup may be the only viable way to get optimized
libraries used.
committed.
distros were not enthusiastic about this approach, but
in the worst case nobody will use these "atomics/" paths
(and we waste a few open syscalls) and in the best case
it enables performance improvement for some users.
2018-06-28 Szabolcs Nagy <szabolcs.nagy@arm.com>
* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h (HWCAP_IMPORTANT): Add
HWCAP_ATOMICS.
---
sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)