Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

[Arjan van de Ven <arjan@linux.intel.com>]

On 6/30/2021 5:22 AM, Enrico Weigelt, metux IT consult wrote:
>>
>> AMX will be shown as enabled in the hardware, but trap into the kernel
>> on first use.  The kernel developers prefer a model where it is checked
>> that the process has previously enabled the feature explicitly, instead
>> relying on lazy initialization as part of the trap (as intended by the
>> hardware design).  This means that the usual CPUID/XCR0 approach (which
>> is reflected in the glibc feature) will not work.
> 
> Ah, now I'm beginning to get it:
> 
> * this feature needs to be initialized first, before it can be used
> * on first use (when not initialized yet), it traps into the kernel
> * we don't want to always initialize it at boot
> 
> Correct ?

not really, the init is PER PROCESS

and then there is a per thread 8Kb state allocation that needs to be context switched/etc
once you actually use AMX.

> 
> What I'm wondering: why shall the process explicitly ask for it and
> why isn't the initialization be done either on bootup or on first use ?

the kernel needs to be able to say "no" in a graceful way, there are several scenarios
(from the sysadmin wanting to manage power/performance/resources to outright compatibility where
the kernel wants or needs to say "no". Most obvious example: if a process asked for an sigaltstack,
we can't let the process use AMX since that stack will be too small most likely to hold
the stackframe)

If you do this on "first use of the instruction" there is no graceful way to say "no".