From: Peter Zijlstra <peterz@infradead.org>
To: Thiago Macieira <thiago.macieira@intel.com>
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 17:27:24 +0200 [thread overview]
Message-ID: <YNnqXCSVUhYhzT6T@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <2379132.fg5cGID6mU@tjmaciei-mobl1>
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:
> > 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 :-(
next prev parent reply other threads:[~2021-06-28 15:50 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 [this message]
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
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=YNnqXCSVUhYhzT6T@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--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=thiago.macieira@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.