From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
libc-alpha@sourceware.org
Cc: nd@arm.com
Subject: Re: aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT
Date: Thu, 19 Apr 2018 17:07:00 -0000 [thread overview]
Message-ID: <02df4e53-258f-ea9c-1381-4420061f7031@arm.com> (raw)
In-Reply-To: <f8f51fdf-14a6-b6e0-87b0-5bf0ca8f9394@linaro.org>
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.
> 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.
> - 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
>
next prev parent reply other threads:[~2018-04-19 17:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-19 11:51 Szabolcs Nagy
2018-04-19 14:38 ` Adhemerval Zanella
2018-04-19 17:07 ` Szabolcs Nagy [this message]
2018-04-19 19:25 ` Adhemerval Zanella
2018-04-30 15:27 ` Carlos O'Donell
2018-04-19 16:08 ` Steve Ellcey
2018-04-19 16:58 ` Szabolcs Nagy
2018-04-30 15:34 ` Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=02df4e53-258f-ea9c-1381-4420061f7031@arm.com \
--to=szabolcs.nagy@arm.com \
--cc=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=nd@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).