lkml.org 
[lkml]   [2024]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 0/2] x86/fpu: Extend kernel_fpu_begin_mask() for the In-Field Scan driver
    From
    On 4/30/24 14:25, Chang S. Bae wrote:
    > The recent update [1] in the SDM highlights the requirement of
    > initializing the AMX state for executing the scan test:
    > "... maintaining AMX state in a non-initialized state ... will
    > prevent the execution of In-Field Scan tests."
    > which is one of CPU state conditions required for the test's execution.

    This ended up just being phrased weirdly. It's a lot more compact to
    just say:

    AMX must be in its init state for In-Field Scan tests to run.

    > In situations where AMX workloads are running, the switched-away active
    > user AMX state remains due to the optimization to reduce the state
    > switching cost. A user state reload is fully completed right before
    > returning to userspace. Consequently, if the switched-in kernel task is
    > executing the scan test, this non-initialized AMX state causes the test
    > to be unable to start.

    FPU state in general (and AMX state in particular) is large and
    expensive to context switch so the kernel tries to leave FPU state alone
    even while running kernel tasks. But, this behavior obviously
    conflicts with the (new) IFS need for AMX must be in its init state.

    Right?

    ..
    > [1] Intel Software Development Manual as of March 2024, Section 18.2
    > RECOMMENDATIONS FOR SYSTEM SOFTWARE of Vol. 1.
    > https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html

    Rather than, "we're just following the spec", I think there can be a
    better explanation here.

    These in-field scan tests (IFS) poke the hardware in unique ways. It
    ends up that IFS and AMX could attempt to use the same hardware
    resources at the same time and step on each other. While it would be
    possible to add additional resources to the CPU to allow simultaneous
    AMX and IFS, the hardware to do this would be relatively expensive. It
    seems pretty reasonable for software to help out here.

    The other argument that could be made is that an admin could isolate the
    CPUs on which they wanted to run an IFS test. They could use cpusets,
    or even the task binding API to try and evict AMX workloads from these
    CPUs. But, the promise of IFS is that it can be run without disturbing
    workloads _too_ much. Basically anything an admin would do is probably
    too onerous and high-impact.

    So this mechanism provides two things: One, it makes the hardware
    simpler and two, it takes the admin out of the picture. Thing just work.



    \
     
     \ /
      Last update: 2024-05-27 18:14    [W:2.609 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site