From: Thiago Macieira <thiago.macieira@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: <fweimer@redhat.com>,
"Enrico Weigelt, metux IT consult" <lkml@metux.net>,
<hjl.tools@gmail.com>, <libc-alpha@sourceware.org>,
<linux-api@vger.kernel.org>, <linux-arch@vger.kernel.org>,
<x86@kernel.org>
Subject: Re: x86 CPU features detection for applications (and AMX)
Date: Mon, 28 Jun 2021 12:26:09 -0700 [thread overview]
Message-ID: <4740900.uQJRkLF2SI@tjmaciei-mobl1> (raw)
In-Reply-To: <20210628190816.GC13401@worktop.programming.kicks-ass.net>
On Monday, 28 June 2021 12:08:16 PDT Peter Zijlstra wrote:
> > Anyway, if the AMX state is a sticky "set once per process", it's likely
> > going to get set early for every process that *may* use AMX. And this is
> > assuming we do the library right and only set it if has AMX code at all,
> > instead of all the time.
>
> This, AFAIU. If the ifunc() resolver finds we haz AMX it can do the
> prctl() and on success pick the AMX routine.
>
> Assuming of course, that if a program links with a library that supports
> AMX, it will actually end up using it.
That's what I meant and I agree. If it has an AMX function for *anything*, it
will do the arch_prctl() and enable the state, even if said function is never
called.
This is the good case. The bad case is that it does the arch_prctl() before it
sees whether there is any AMX function.
Do we expect that the dynamic loader will have this code? It currently
searches the multiple ABI levels (up to x86-64-v4 to include AVX512) and HW
capabilities. I can readily see AMX being one of the capabilities, if not an
ABI level. Though it should be trivial for it to call the arch_prctl() if and
only if it is about to load an ELF module that declares use of AMX and also
*not* load it if the syscall fails.
$ LD_DEBUG=libs /lib64/ld-linux-x86-64.so.2 --inhibit-cache /bin/ls
1620: find library=librt.so.1 [0]; searching
1620: search path=.....
1620: trying file=/usr/lib64/glibc-hwcaps/x86-64-v4/librt.so.1
1620: trying file=/usr/lib64/glibc-hwcaps/x86-64-v3/librt.so.1
1620: trying file=/usr/lib64/glibc-hwcaps/x86-64-v2/librt.so.1
1620: trying file=/usr/lib64/tls/haswell/avx512_1/x86_64/librt.so.
1
1620: trying file=/usr/lib64/tls/haswell/avx512_1/librt.so.1
1620: trying file=/usr/lib64/tls/haswell/x86_64/librt.so.1
1620: trying file=/usr/lib64/tls/haswell/librt.so.1
1620: trying file=/usr/lib64/tls/avx512_1/x86_64/librt.so.1
1620: trying file=/usr/lib64/tls/avx512_1/librt.so.1
1620: trying file=/usr/lib64/tls/x86_64/librt.so.1
1620: trying file=/usr/lib64/tls/librt.so.1
1620: trying file=/usr/lib64/haswell/avx512_1/x86_64/librt.so.1
1620: trying file=/usr/lib64/haswell/avx512_1/librt.so.1
1620: trying file=/usr/lib64/haswell/x86_64/librt.so.1
1620: trying file=/usr/lib64/haswell/librt.so.1
1620: trying file=/usr/lib64/avx512_1/x86_64/librt.so.1
1620: trying file=/usr/lib64/avx512_1/librt.so.1
1620: trying file=/usr/lib64/x86_64/librt.so.1
1620: trying file=/usr/lib64/librt.so.1
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
next prev parent reply other threads:[~2021-06-28 19:26 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-23 15:04 x86 CPU features detection for applications (and AMX) Florian Weimer
2021-06-23 15:32 ` Dave Hansen
2021-07-08 6:05 ` Florian Weimer
2021-07-08 14:19 ` Dave Hansen
2021-07-08 14:31 ` Florian Weimer
2021-07-08 14:36 ` Dave Hansen
2021-07-08 14:41 ` Florian Weimer
2021-06-25 23:31 ` Thiago Macieira
2021-06-28 12:40 ` Enrico Weigelt, metux IT consult
2021-06-28 13:20 ` Peter Zijlstra
2021-06-30 12:50 ` Enrico Weigelt, metux IT consult
2021-06-30 15:36 ` Thiago Macieira
2021-07-01 7:35 ` Enrico Weigelt, metux IT consult
2021-06-28 15:08 ` Thiago Macieira
2021-06-28 15:27 ` Peter Zijlstra
2021-06-28 16:13 ` Thiago Macieira
2021-06-28 17:11 ` Peter Zijlstra
2021-06-28 17:23 ` Thiago Macieira
2021-06-28 19:08 ` Peter Zijlstra
2021-06-28 19:26 ` Thiago Macieira [this message]
2021-06-28 17:43 ` Peter Zijlstra
2021-06-28 19:05 ` Thiago Macieira
2021-06-30 14:32 ` Enrico Weigelt, metux IT consult
2021-06-30 14:34 ` Florian Weimer
2021-06-30 15:16 ` Enrico Weigelt, metux IT consult
2021-06-30 15:38 ` Florian Weimer
2021-07-01 8:08 ` Enrico Weigelt, metux IT consult
2021-07-01 8:21 ` Florian Weimer
2021-07-01 11:59 ` Enrico Weigelt, metux IT consult
2021-07-06 12:57 ` Florian Weimer
2021-06-30 15:29 ` Thiago Macieira
2021-07-01 11:57 ` Enrico Weigelt, metux IT consult
2021-07-08 7:08 ` Florian Weimer
2021-07-08 15:13 ` Thiago Macieira
2021-07-08 17:56 ` Mark Brown
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=4740900.uQJRkLF2SI@tjmaciei-mobl1 \
--to=thiago.macieira@intel.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=lkml@metux.net \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
/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 NNTP newsgroup(s).