From: Noah Goldstein <goldstein.w.n@gmail.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Len Brown <lenb@kernel.org>, Florian Weimer <fweimer@redhat.com>,
Rich Felker <dalias@libc.org>,
libc-alpha <libc-alpha@sourceware.org>,
Greg KH <gregkh@linuxfoundation.org>,
"Bae, Chang Seok" <chang.seok.bae@intel.com>,
X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Dave Hansen <dave.hansen@intel.com>, Kyle Huey <me@kylehuey.com>,
Linux API <linux-api@vger.kernel.org>,
Keno Fischer <keno@juliacomputing.com>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
Date: Tue, 30 Mar 2021 01:50:29 -0400 [thread overview]
Message-ID: <CAFUsyfK=kfvMW9Ug2t36hfV+OAbVHJ7dwy9dEvE3LMXYEvtmYQ@mail.gmail.com> (raw)
In-Reply-To: <CALCETrV_sQnu0u+wKZrAL2-500EHoQ6d4LgRhCWwRhK-4Z3X7A@mail.gmail.com>
Forgive if this is silly but would it be possible to do something
simliar to rseq where the user can register a set of features for a
program counter region and then on interrupt check that to determine
what needs to be saved?
For example if a user doesn't use any AMX but loads a library that
does, for all ip in the users code AMX state won't be saved but an
interrupt in ip range of the library will save AMX state.
One advantage of this is it would be pretty easy silently do this
right with compiler support and to preserve old code the "ip not found
in table" case could default to the worst case the CPU supports.
On Tue, Mar 30, 2021 at 1:09 AM Andy Lutomirski via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On Mon, Mar 29, 2021 at 3:38 PM Len Brown <lenb@kernel.org> wrote:
> >
> > On Mon, Mar 29, 2021 at 2:16 PM Andy Lutomirski <luto@amacapital.net> wrote:
> > >
>
> > Hi Andy,
> >
> > Can you provide a concise definition of the exact problemI(s) this thread
> > is attempting to address?
>
> The AVX-512 state, all by itself, is more than 2048 bytes. Quoting
> the POSIX sigaltstack page (man 3p sigaltstack):
>
> The value SIGSTKSZ is a system default specifying the number of bytes
> that would be used to cover the usual case when manually allocating an
> alternate stack area. The value MINSIGSTKSZ is defined to be the mini‐
> mum stack size for a signal handler. In computing an alternate stack
> size, a program should add that amount to its stack requirements to al‐
> low for the system implementation overhead. The constants SS_ONSTACK,
> SS_DISABLE, SIGSTKSZ, and MINSIGSTKSZ are defined in <signal.h>.
>
> arch/x86/include/uapi/asm/signal.h:#define MINSIGSTKSZ 2048
> arch/x86/include/uapi/asm/signal.h:#define SIGSTKSZ 8192
>
> Regrettably, the Linux signal frame format is the uncompacted format
> and, also regrettably, the uncompacted format has the nasty property
> that its format depends on XCR0 but not on the set of registers that
> are actually used or wanted, so, with the current ABI, the signal
> frame is stuck being quite large for all programs on a machine that
> supports avx512 and has it enabled by the kernel. And it's even
> larger for AMX and violates SIGSTKSZ as well as MINSTKSZ.
>
> There are apparently real programs that break as a result. We need to
> find a way to handle new, large extended states without breaking user
> ABI. We should also find a way to handle them without consuming silly
> amounts of stack space for programs that don't use them.
>
> Sadly, if the solution we settle on involves context switching XCR0,
> performance on first-generation hardware will suffer because VMX does
> not have any way to allow guests to write XCR0 without exiting. I
> don't consider this to be a showstopper -- if we end up having this
> problem, fixing it in subsequent CPUs is straightforward.
>
> >
> > Thank ahead-of-time for excluding "blow up power consumption",
> > since that paranoia is not grounded in fact.
> >
>
> I will gladly exclude power consumption from this discussion, since
> that's a separate issue that has nothing to do with the user<->kernel
> ABI.
next prev parent reply other threads:[~2021-03-30 5:51 UTC|newest]
Thread overview: 130+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-26 23:12 Candidate Linux ABI for Intel AMX and hypothetical new related features Andy Lutomirski
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 [this message]
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
2021-03-31 8:24 ` Borislav Petkov
[not found] ` <87lf9nk2ku.fsf@oldenburg.str.redhat.com>
2021-04-12 14:31 ` Borislav Petkov
2021-04-12 14:38 ` Florian Weimer
2021-04-12 15:08 ` Borislav Petkov
2021-04-12 15:10 ` Andy Lutomirski
2021-04-12 15:21 ` Andy Lutomirski
2021-04-12 23:46 ` Len Brown
2021-04-13 0:17 ` Thomas Gleixner
2021-04-13 1:25 ` Len Brown
2021-04-13 3:43 ` Willy Tarreau
2021-04-13 19:51 ` Len Brown
2021-04-14 9:58 ` Borislav Petkov
2021-04-14 10:06 ` Willy Tarreau
2021-04-14 10:08 ` Borislav Petkov
2021-04-14 21:57 ` Len Brown
2021-04-15 4:43 ` Borislav Petkov
2021-04-15 5:29 ` Willy Tarreau
2021-04-15 5:47 ` Borislav Petkov
2021-04-16 22:05 ` Len Brown
2021-04-19 14:14 ` Borislav Petkov
2021-04-19 18:18 ` Len Brown
2021-04-19 19:15 ` Borislav Petkov
2021-04-19 21:33 ` Len Brown
2021-04-19 21:58 ` Borislav Petkov
2021-04-23 19:35 ` Len Brown
2021-04-23 19:57 ` Borislav Petkov
2021-05-02 15:27 ` Len Brown
2021-05-03 5:18 ` Florian Weimer
2021-05-03 13:43 ` Dave Hansen
2021-05-03 13:47 ` Florian Weimer
2021-05-03 14:14 ` Dave Hansen
2021-05-07 18:44 ` Thomas Gleixner
2021-05-07 18:50 ` Andy Lutomirski
2021-05-07 19:22 ` Thomas Gleixner
2021-05-08 9:45 ` Thomas Gleixner
2021-05-18 20:39 ` Len Brown
2021-05-19 23:29 ` Andy Lutomirski
2021-05-20 19:16 ` Len Brown
2021-05-17 9:45 ` 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
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
2021-04-19 23:52 ` Paul Eggert
2021-04-13 20:16 ` Andy Lutomirski
2021-04-13 22:47 ` Len Brown
2021-04-13 22:58 ` Andy Lutomirski
2021-04-14 21:48 ` Len Brown
2021-04-15 16:24 ` Andy Lutomirski
2021-04-15 17:00 ` Dave Hansen
2021-04-15 17:38 ` Andy Lutomirski
2021-04-16 21:54 ` Len Brown
2021-04-16 22:03 ` Andy Lutomirski
2021-04-16 22:10 ` Len Brown
2021-04-16 22:14 ` Andy Lutomirski
2021-04-17 1:57 ` Len 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='CAFUsyfK=kfvMW9Ug2t36hfV+OAbVHJ7dwy9dEvE3LMXYEvtmYQ@mail.gmail.com' \
--to=goldstein.w.n@gmail.com \
--cc=chang.seok.bae@intel.com \
--cc=dalias@libc.org \
--cc=dave.hansen@intel.com \
--cc=fweimer@redhat.com \
--cc=gregkh@linuxfoundation.org \
--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=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).