lkml.org 
[lkml]   [2021]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Candidate Linux ABI for Intel AMX and hypothetical new related features
Date
* 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?

> 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.

Now it turns out that we can still support this in glibc because of the
pointer indirection, but only if the kernel provides a bit we can read
in thread-specific data.

> 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.)

Thanks,
Florian

\
 
 \ /
  Last update: 2021-06-28 14:50    [W:0.174 / U:1.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site