From: Florian Weimer <fweimer@redhat.com>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Cc: Len Brown <lenb@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Dave Hansen via Libc-alpha <libc-alpha@sourceware.org>,
Dave Hansen <dave.hansen@intel.com>,
Rich Felker <dalias@libc.org>,
Linux API <linux-api@vger.kernel.org>,
"Bae, Chang Seok" <chang.seok.bae@intel.com>,
X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Kyle Huey <me@kylehuey.com>, Borislav Petkov <bp@alien8.de>,
Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Keno Fischer <keno@juliacomputing.com>,
Arjan van de Ven <arjan@linux.intel.com>,
Willy Tarreau <w@1wt.eu>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
Date: Mon, 28 Jun 2021 14:49:45 +0200 [thread overview]
Message-ID: <87tulirw5y.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <93e3b500-5992-a674-18e6-445d1db7b1f0@metux.net> (Enrico Weigelt's message of "Mon, 28 Jun 2021 12:14:02 +0200")
* Enrico Weigelt:
> On 24.06.21 01:11, Len Brown wrote:
>>> x86 CPU features detection for applications (and AMX)
>>> <https://lore.kernel.org/linux-api/87tulo39ms.fsf@oldenburg.str.redhat.com/>
>> FWIW, I didn't receive it, because you excluded
>> linux-kernel@vger.kernel.org
>
> me neither :(
>
> Maybe just repost it to LKML ?
Isn't it sufficient to start Cc:ing the list?
> You mention the interface *was* designed with cpu features remaining
> constant over a process' lifetime. Between the line I'm reading that
> this might not be the case anymore.
>
> How could that happen ? Process migration on a different CPU (or perhaps
> on a different host) ?
AMX will be shown as enabled in the hardware, but trap into the kernel
on first use. The kernel developers prefer a model where it is checked
that the process has previously enabled the feature explicitly, instead
relying on lazy initialization as part of the trap (as intended by the
hardware design). This means that the usual CPUID/XCR0 approach (which
is reflected in the glibc feature) will not work.
Now it turns out that we can still support this in glibc because of the
pointer indirection, but only if the kernel provides a bit we can read
in thread-specific data.
> Damn, how could the cpu designers come up with such weird concepts
> in the first place ? :o
It's not the CPU designers. The CPU behaves according to the old model.
(I consider the old model a success, despite all the challenges, but not
everyone agrees, obviosly.)
Thanks,
Florian
next prev parent reply other threads:[~2021-06-28 12:49 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210415044258.GA6318@zn.tnic>
[not found] ` <20210415052938.GA2325@1wt.eu>
[not found] ` <20210415054713.GB6318@zn.tnic>
[not found] ` <CAJvTdKnjzAMh3N_c7KP3kA=e0LgYHgCANg44oJp3LcSm7dtbSQ@mail.gmail.com>
[not found] ` <20210419141454.GE9093@zn.tnic>
[not found] ` <CAJvTdK=p8mgO3xw9sRxu0c7NTNTG109M442b3UZh8TqLLfkC1Q@mail.gmail.com>
[not found] ` <20210419191539.GH9093@zn.tnic>
[not found] ` <CAJvTdK=VnG94ECcRVoUi8HrCbVEKc8X4_JmRTkqe+vTttf0Wsg@mail.gmail.com>
[not found] ` <20210419215809.GJ9093@zn.tnic>
[not found] ` <CAJvTdKn6JHo02karEs0e5g+6SimS5VUcXKjCkX35WY+xkgAgxw@mail.gmail.com>
[not found] ` <YIMmwhEr46VPAZa4@zn.tnic>
[not found] ` <CAJvTdKnhXnynybS4eNEF_EtF26auyb-mhKLNd1D9_zvCrchZsw@mail.gmail.com>
2021-05-17 9:45 ` Candidate Linux ABI for Intel AMX and hypothetical new related features Thomas Gleixner
2021-05-17 9:56 ` Florian Weimer
2021-05-17 10:18 ` Thomas Gleixner
2021-05-21 16:29 ` Len Brown
2021-05-17 13:49 ` Arjan van de Ven
2021-05-20 15:35 ` Len Brown
2021-05-20 20:54 ` Thomas Gleixner
2021-05-20 21:13 ` Dave Hansen
2021-05-20 21:41 ` Len Brown
2021-05-20 22:53 ` Dave Hansen
2021-05-21 9:41 ` Thomas Gleixner
2021-05-21 14:44 ` Florian Weimer
2021-05-21 14:49 ` Peter Zijlstra
2021-06-23 15:06 ` Florian Weimer
2021-06-23 23:11 ` Len Brown
2021-06-28 10:14 ` Enrico Weigelt, metux IT consult
2021-06-28 12:49 ` Florian Weimer [this message]
2021-06-30 12:22 ` Enrico Weigelt, metux IT consult
2021-06-30 12:41 ` Willy Tarreau
2021-06-30 13:55 ` Arjan van de Ven
2021-06-30 15:20 ` Len Brown
2021-06-30 15:25 ` Enrico Weigelt, metux IT consult
2021-05-21 16:14 ` Dave Hansen
2021-05-21 16:19 ` Florian Weimer
2021-05-21 16:26 ` Len Brown
2021-05-21 16:28 ` Dave Hansen
2021-05-21 16:31 ` Andy Lutomirski
2021-05-21 19:10 ` Thomas Gleixner
2021-05-21 20:07 ` Andy Lutomirski
2021-05-21 21:43 ` Thomas Gleixner
2021-05-21 22:07 ` Len Brown
2021-05-21 22:46 ` Thomas Gleixner
2021-05-21 23:31 ` Len Brown
2021-05-22 7:16 ` Florian Weimer
2021-05-22 23:55 ` Andy Lutomirski
2021-05-21 23:06 ` Dave Hansen
2021-05-21 23:08 ` Len Brown
2021-05-21 19:05 ` Thomas Gleixner
2021-05-20 21:22 ` Len Brown
2021-05-20 21:41 ` Thomas Gleixner
2021-05-20 21:49 ` Len Brown
2021-05-21 9:26 ` Thomas Gleixner
[not found] <CALCETrW2QHa2TLvnUuVxAAheqcbSZ-5_WRXtDSAGcbG8N+gtdQ@mail.gmail.com>
2021-03-26 23:18 ` Andy Lutomirski
2021-03-27 3:39 ` Len Brown
2021-03-27 9:14 ` Borislav Petkov
2021-03-27 9:58 ` Greg KH
2021-03-29 15:47 ` Len Brown
2021-03-29 16:38 ` Len Brown
2021-03-29 16:48 ` Florian Weimer
2021-03-29 18:14 ` Andy Lutomirski
2021-03-29 18:16 ` Andy Lutomirski
2021-03-29 22:38 ` Len Brown
2021-03-30 5:08 ` Andy Lutomirski
2021-03-30 5:50 ` Noah Goldstein
2021-03-30 17:01 ` Len Brown
2021-03-30 17:05 ` Andy Lutomirski
2021-03-30 17:56 ` Len Brown
2021-03-30 19:12 ` Dave Hansen
2021-03-30 20:20 ` Andy Lutomirski
2021-03-30 20:42 ` Len Brown
2021-03-30 22:01 ` David Laight
2021-03-31 16:31 ` Len Brown
2021-03-31 16:53 ` Andy Lutomirski
2021-03-31 21:42 ` Robert O'Callahan
2021-03-31 22:11 ` Len Brown
2021-03-31 22:28 ` Len Brown
2021-03-31 22:45 ` Andy Lutomirski
2021-04-09 20:52 ` Len Brown
2021-04-09 21:44 ` Andy Lutomirski
2021-04-11 19:07 ` Len Brown
2021-04-12 7:59 ` David Laight
2021-04-12 12:19 ` Borislav Petkov
2021-04-12 17:14 ` Sean Christopherson
2021-03-31 22:52 ` Borislav Petkov
2021-04-09 20:55 ` Len Brown
2021-03-28 0:53 ` Thomas Gleixner
2021-03-29 7:27 ` Peter Zijlstra
2021-03-29 15:06 ` Dave Hansen
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=87tulirw5y.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=arjan@linux.intel.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=dalias@libc.org \
--cc=dave.hansen@intel.com \
--cc=keno@juliacomputing.com \
--cc=lenb@kernel.org \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@metux.net \
--cc=luto@kernel.org \
--cc=me@kylehuey.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=w@1wt.eu \
--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).