Re: aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 19/04/2018 14:06, Szabolcs Nagy wrote:
> On 19/04/18 15:38, Adhemerval Zanella wrote:
>> On 19/04/2018 08:51, 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'm not familiar with how this feature of the dynamic linker is used
>>> in practice by distros or others so comments are welcome.
>>
>> Clearlinux seems to use this to provide optimized Intel libraries [1].
>>
> 
> interesting thanks.
> 
>>> 2018-04-19  Szabolcs Nagy  <szabolcs.nagy@arm.com>
>>>
>>>      * sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h (HWCAP_IMPORTANT): Add
>>>      HWCAP_ATOMICS.
>>
>> I think what you want is something what x86_64 has done [2]: on cpu-features.c
>> the code creates a list of possible processor specific paths and sets it do
>> GLRO(dl_platform) (for instance on x86_64 if the underlying system is a haswell
>> it will add the haswell folder path).
>>
>> Currently since AArch64 do not change dl_platform_init, it adds 'aarch64' from
>> AT_PLATFORM and 'cpuid' because of HWCAP_IMPORTANT.  IMHO neither does make
>> sense as search paths, I would expect at least the 'cpu_list' from aarch
>> cpu-features.c (maybe by excluding the 'generic' field).
>>
> 
> i don't know the reasons behind 'aarch64' and 'tls' search paths
> and i have no particular attachment to the HWCAP_IMPORTANT mechanism.

'aarch64' came from default code at elf/dl-sysdep.c if the platform does
not override the dl_platform (and the code to set AT_PLATFORM on dl_platform
is from commit 0a54e401).  My guess is to provide a direct way to difference
ABI folders for bi-arch system (x86_64 and i686 for instance).

I think for aarch64 there is no direct gain in adding 'aarch64' in search
path.

> 
>> So I suggest to rework how aarch64 obtain the search path by setting the
>> dl_platform in cpu-features.c:
>>
>>    - We can get the cpu_list if HWCAP_CPUID, so add only current cpu folder
>>      if it the case.
>>
>>    - If HWCAP_ATOMICS is set add 'lse'.
>>
> 
> if these paths are for optimization only then i guess the list
> can change between libc releases without causing issues other
> than performance regressions.
> 
> in that case i'm in favor of removing unnecessary search paths.
> 
> atomics i think is a useful variant, i'll think about the cpuid
> based search paths, i don't want too many variants since nobody
> will prepare/test binaries for all uarch variants, but i do like
> the ability to have alternative optimized libs.

I think adding just 'lse' (or other meaningful name) should be suffice
for now.  If cavium/qualcomm/etc desire, they can propose adding more
search paths based on their requirements.

> 
>>    - Any more required?
>>
>> [1] https://clearlinux.org/blogs/transparent-use-library-packages-optimized-intel-architecture
>> [2] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1432d38ea04ab5e96f21a38;hp=3b5f801ddb838311b5b05c218caac3bdb00d7c95
>>
>