• Dave Hansen's avatar
    x86/fpu: Optimize out sigframe xfeatures when in init state · 30d02551
    Dave Hansen authored
    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: 2308ee57 ("x86/fpu/amx: Enable the AMX feature in 64-bit mode")
    Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Tested-by: default avatar"Chang S. Bae" <chang.seok.bae@intel.com>
    Link: https://lore.kernel.org/r/20211102224750.FA412E26@davehans-spike.ostc.intel.com
    30d02551
xstate.h 4.29 KB