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

[Len Brown]

On Thu, Apr 15, 2021 at 1:47 AM Borislav Petkov <bp@xxxxxxxxx> wrote:

> What I'd like to see is 0-overhead for current use cases and only
> overhead for those who want to use it. If that can't be done
> automagically, then users should request it explicitly. So basically you
> blow up the xsave buffer only for processes which want to do AMX.

Indeed, expanding the xsave buffer happens only for tasks that touch
AMX TILE registers.

> And this brings the question about libraries which, if they start using
> AMX by default - which doesn't sound like they will want to because AMX
> reportedly will have only a limited? set of users - if libraries start
> using it by default, then it better be worth the handling of the 8kb
> buffer per process.

I'm not aware of any intent to transparently use AMX for bcopy, like
what happened
with AVX-512.  (didn't they undo that mistake?)

> If not, this should also be requestable per process so that a simple
> pipe in Linux:
>
> <process> | grep | awk | sed ...
>
> and so on is not penalized to allocate and handle by default 8kb for
> *each* process' buffer in that pipe just because each is linking against
> glibc which has detected AMX support in CPUID and is using it too for
> some weird reason like some microbenchmark saying so.

Tasks are created without an 8KB AMX buffer.
Tasks have to actually touch the AMX TILE registers for us to allocate
one for them.

> But my initial question was on the "establishing" part and was asking
> where we have established anything wrt AMX.

The patch set on LKML establishes working AMX Linux support in public.
I am thankful for your and other public review and feedback on that series.
I can think of 3 actual bugs that were found in the process.

thanks,
Len Brown Intel Open Source Technology Center