From: Thomas Gleixner <tglx@linutronix.de>
To: Florian Weimer <fweimer@redhat.com>, Dave Hansen <dave.hansen@intel.com>
Cc: Dave Hansen via Libc-alpha <libc-alpha@sourceware.org>,
Len Brown <lenb@kernel.org>, 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>,
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: Fri, 21 May 2021 21:05:12 +0200 [thread overview]
Message-ID: <87mtsnaown.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <87r1i06ow2.fsf@oldenburg.str.redhat.com>
On Fri, May 21 2021 at 18:19, Florian Weimer wrote:
> * Dave Hansen:
>> On 5/21/21 7:44 AM, Florian Weimer wrote:
>>> Why can't userspace look at XCR0 to make the decision?
>>
>> The thing we're trying to avoid is a #NM exception from XFD (the new
>> first-use detection feature) that occurs on the first use of AMX.
>> XCR0 will have XCR0[AMX]=1, even if XFD is "armed" and ready to
>> generate the #NM.
>
> I see. So essentially the hardware wants to offer transparent
> initialize-on-use, but Linux does not seem to want to implement it this
> way.
The hardware offers an exception which can be used to implement that,
but the hardware does not dictate that usage.
If we'd go that way we lost any control over that resource and I can
demonstrate with AVX512 today what kind of consequences that has with
mixed criticality realtime workloads.
The only solution we have today is to disable AVX512 completely, which
sucks because restricted usage can be benefitial for some of the
computations.
The problem is that the approach of user space in general seems to be
blindly_select_max(AVX). I've seen that in quite some places.
With AMX (and the stuff coming next) we have the chance to do proper
resource control and it would be outright stupid not to take that
opportunity.
Thanks,
tglx
next prev parent reply other threads:[~2021-05-21 19:05 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
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 [this message]
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=87mtsnaown.ffs@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--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=fweimer@redhat.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=luto@kernel.org \
--cc=me@kylehuey.com \
--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).