Thread (30 messages) flat view 30 messages, 6 authors, 2021-07-08

Re: x86 CPU features detection for applications (and AMX)

From: Peter Zijlstra <peterz@infradead.org>
Date: 2021-06-28 15:50:19
Also in: linux-arch

On Mon, Jun 28, 2021 at 08:08:41AM -0700, Thiago Macieira wrote:
On Monday, 28 June 2021 05:40:32 PDT Enrico Weigelt, metux IT consult wrote:
quoted
What we SW engineers need is an easy and fast method to act depending on
whether some CPU supports some feature (eg. a new opcode). Things like
cpuinfo are only a tiny piece of that. What we could really use is a
conditional jump/call based on whether feature X is supported - without
any kernel intervention. Then the machine code could be easily layed out
to support both cases with our without some feature X. Alternatively we
could have a fast trapping in useland - hw generated call already would
be a big help.
That's what cpuid is for. With GCC function multi-versioning or equivalent 
manually-rolled solutions, you can get exactly what you're asking for.
Right, lots of self-modifying code solutions there, some of which can be
linker driven, some not. In the kernel we use alternative() to replace
short code sequences depending on CPUID.

Userspace *could* do the same, rewriting code before first execution is
fairly straight forward.
Yes, the checking became far more complex with the need to check XCR0 after 
AVX came along, but since the instruction itself is a slow and serialising, 
any library will just cache the results. And as a result, the level of CPU 
features is not expected to change. It never has in the past, so this hasn't 
been an issue.
Arguably you should be checking XCR0 for any feature there, including
SSE/AVX/AVX512 and now AMX.

Ideally we'd do a prctl() for AVX512 too, except it's too late :-(
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help