Messages in this thread | | | Subject | Re: Candidate Linux ABI for Intel AMX and hypothetical new related features | From | "Enrico Weigelt, metux IT consult" <> | Date | Wed, 30 Jun 2021 14:22:19 +0200 |
| |
On 28.06.21 14:49, Florian Weimer wrote: > * Enrico Weigelt: > >> On 24.06.21 01:11, Len Brown wrote: >>>> x86 CPU features detection for applications (and AMX) >>>> <https://lore.kernel.org/linux-api/87tulo39ms.fsf@oldenburg.str.redhat.com/> >>> FWIW, I didn't receive it, because you excluded >>> linux-kernel@vger.kernel.org >> >> me neither :( >> >> Maybe just repost it to LKML ? > > Isn't it sufficient to start Cc:ing the list?
Well, in that case people probably missed the original mail. (maybe, I'm too lazy for searching the web for archives ... :P)
>> You mention the interface *was* designed with cpu features remaining >> constant over a process' lifetime. Between the line I'm reading that >> this might not be the case anymore. >> >> How could that happen ? Process migration on a different CPU (or perhaps >> on a different host) ? > > 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 ?
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 ?
>> Damn, how could the cpu designers come up with such weird concepts >> in the first place ? :o > > It's not the CPU designers. The CPU behaves according to the old model. > (I consider the old model a success, despite all the challenges, but not > everyone agrees, obviosly.)
I'm still claiming already this old model is a horrible misdesign and (most of) the extensions made over the decades are anything but well designed - there had been many changes to do it much, much better. For example there would have been ways to introduce new opcodes in a way that they can be easily emulated in kernel or userland, w/o going through a full trap.
But that's gonna be a long discussion on its own, probably getting offtopic here.
--mtx
-- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287
| |