mirror of
https://github.com/torvalds/linux.git
synced 2024-11-23 12:42:02 +00:00
30d02551ba
tl;dr: AMX state is ~8k. Signal frames can have space for this
~8k and each signal entry writes out all 8k even if it is zeros.
Skip writing zeros for AMX to speed up signal delivery by about
4% overall when AMX is in its init state.
This is a user-visible change to the sigframe ABI.
== Hardware XSAVE Background ==
XSAVE state components may be tracked by the processor as being
in their initial configuration. Software can detect which
features are in this configuration by looking at the XSTATE_BV
field in an XSAVE buffer or with the XGETBV(1) instruction.
Both the XSAVE and XSAVEOPT instructions enumerate features s
being in the initial configuration via the XSTATE_BV field in the
XSAVE header, However, XSAVEOPT declines to actually write
features in their initial configuration to the buffer. XSAVE
writes the feature unconditionally, regardless of whether it is
in the initial configuration or not.
Basically, XSAVE users never need to inspect XSTATE_BV to
determine if the feature has been written to the buffer.
XSAVEOPT users *do* need to inspect XSTATE_BV. They might also
need to clear out the buffer if they want to make an isolated
change to the state, like modifying one register.
== Software Signal / XSAVE Background ==
Signal frames have historically been written with XSAVE itself.
Each state is written in its entirety, regardless of being in its
initial configuration.
In other words, the signal frame ABI uses the XSAVE behavior, not
the XSAVEOPT behavior.
== Problem ==
This means that any application which has acquired permission to
use AMX via ARCH_REQ_XCOMP_PERM will write 8k of state to the
signal frame. This 8k write will occur even when AMX was in its
initial configuration and software *knows* this because of
XSTATE_BV.
This problem also exists to a lesser degree with AVX-512 and its
2k of state. However, AVX-512 use does not require
ARCH_REQ_XCOMP_PERM and is more likely to have existing users
which would be impacted by any change in behavior.
== Solution ==
Stop writing out AMX xfeatures which are in their initial state
to the signal frame. This effectively makes the signal frame
XSAVE buffer look as if it were written with a combination of
XSAVEOPT and XSAVE behavior. Userspace which handles XSAVEOPT-
style buffers should be able to handle this naturally.
For now, include only the AMX xfeatures: XTILE and XTILEDATA in
this new behavior. These require new ABI to use anyway, which
makes their users very unlikely to be broken. This XSAVEOPT-like
behavior should be expected for all future dynamic xfeatures. It
may also be extended to legacy features like AVX-512 in the
future.
Only attempt this optimization on systems with dynamic features.
Disable dynamic feature support (XFD) if XGETBV1 is unavailable
by adding a CPUID dependency.
This has been measured to reduce the *overall* cycle cost of
signal delivery by about 4%.
Fixes: 2308ee57d9 ("x86/fpu/amx: Enable the AMX feature in 64-bit mode")
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: "Chang S. Bae" <chang.seok.bae@intel.com>
Link: https://lore.kernel.org/r/20211102224750.FA412E26@davehans-spike.ostc.intel.com
75 lines
3.2 KiB
ReStructuredText
75 lines
3.2 KiB
ReStructuredText
Using XSTATE features in user space applications
|
|
================================================
|
|
|
|
The x86 architecture supports floating-point extensions which are
|
|
enumerated via CPUID. Applications consult CPUID and use XGETBV to
|
|
evaluate which features have been enabled by the kernel XCR0.
|
|
|
|
Up to AVX-512 and PKRU states, these features are automatically enabled by
|
|
the kernel if available. Features like AMX TILE_DATA (XSTATE component 18)
|
|
are enabled by XCR0 as well, but the first use of related instruction is
|
|
trapped by the kernel because by default the required large XSTATE buffers
|
|
are not allocated automatically.
|
|
|
|
Using dynamically enabled XSTATE features in user space applications
|
|
--------------------------------------------------------------------
|
|
|
|
The kernel provides an arch_prctl(2) based mechanism for applications to
|
|
request the usage of such features. The arch_prctl(2) options related to
|
|
this are:
|
|
|
|
-ARCH_GET_XCOMP_SUPP
|
|
|
|
arch_prctl(ARCH_GET_XCOMP_SUPP, &features);
|
|
|
|
ARCH_GET_XCOMP_SUPP stores the supported features in userspace storage of
|
|
type uint64_t. The second argument is a pointer to that storage.
|
|
|
|
-ARCH_GET_XCOMP_PERM
|
|
|
|
arch_prctl(ARCH_GET_XCOMP_PERM, &features);
|
|
|
|
ARCH_GET_XCOMP_PERM stores the features for which the userspace process
|
|
has permission in userspace storage of type uint64_t. The second argument
|
|
is a pointer to that storage.
|
|
|
|
-ARCH_REQ_XCOMP_PERM
|
|
|
|
arch_prctl(ARCH_REQ_XCOMP_PERM, feature_nr);
|
|
|
|
ARCH_REQ_XCOMP_PERM allows to request permission for a dynamically enabled
|
|
feature or a feature set. A feature set can be mapped to a facility, e.g.
|
|
AMX, and can require one or more XSTATE components to be enabled.
|
|
|
|
The feature argument is the number of the highest XSTATE component which
|
|
is required for a facility to work.
|
|
|
|
When requesting permission for a feature, the kernel checks the
|
|
availability. The kernel ensures that sigaltstacks in the process's tasks
|
|
are large enough to accommodate the resulting large signal frame. It
|
|
enforces this both during ARCH_REQ_XCOMP_SUPP and during any subsequent
|
|
sigaltstack(2) calls. If an installed sigaltstack is smaller than the
|
|
resulting sigframe size, ARCH_REQ_XCOMP_SUPP results in -ENOSUPP. Also,
|
|
sigaltstack(2) results in -ENOMEM if the requested altstack is too small
|
|
for the permitted features.
|
|
|
|
Permission, when granted, is valid per process. Permissions are inherited
|
|
on fork(2) and cleared on exec(3).
|
|
|
|
The first use of an instruction related to a dynamically enabled feature is
|
|
trapped by the kernel. The trap handler checks whether the process has
|
|
permission to use the feature. If the process has no permission then the
|
|
kernel sends SIGILL to the application. If the process has permission then
|
|
the handler allocates a larger xstate buffer for the task so the large
|
|
state can be context switched. In the unlikely cases that the allocation
|
|
fails, the kernel sends SIGSEGV.
|
|
|
|
Dynamic features in signal frames
|
|
---------------------------------
|
|
|
|
Dynamcally enabled features are not written to the signal frame upon signal
|
|
entry if the feature is in its initial configuration. This differs from
|
|
non-dynamic features which are always written regardless of their
|
|
configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV
|
|
field to determine if a features was written.
|