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

3 messages, 3 authors, 2021-06-28 · open the first message on its own page

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

From: Florian Weimer <hidden>
Date: 2021-06-23 15:07:36

* Peter Zijlstra:
On Fri, May 21, 2021 at 04:44:58PM +0200, Florian Weimer wrote:
quoted
And we added an interface for querying x86 CPU features to glibc 2.33
which is completely incompatible with this because it assumes that CPU
features do not change during the lifetime of a process. 8-(
How many x86 kernel maintainers signed off on that patch?
I've started a new thread:

  x86 CPU features detection for applications (and AMX)
  <https://lore.kernel.org/linux-api/87tulo39ms.fsf@oldenburg.str.redhat.com/>

Thanks,
Florian

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

From: Len Brown <lenb@kernel.org>
Date: 2021-06-23 23:12:09

On Wed, Jun 23, 2021 at 11:07 AM Florian Weimer [off-list ref] wrote:
* Peter Zijlstra:
quoted
On Fri, May 21, 2021 at 04:44:58PM +0200, Florian Weimer wrote:
quoted
And we added an interface for querying x86 CPU features to glibc 2.33
which is completely incompatible with this because it assumes that CPU
features do not change during the lifetime of a process. 8-(
How many x86 kernel maintainers signed off on that patch?
I've started a new thread:

  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

(x86@kernel.org is just the actual x86 kernel committers, ISTR)

Len Brown, Intel Open Source Technology Center

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

From: Enrico Weigelt, metux IT consult <hidden>
Date: 2021-06-28 10:15:08

On 24.06.21 01:11, Len Brown wrote:
quoted
   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 ?

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

This is gonna be tricky, because this somehow needs to be synchronized
with the application (even if we check the bits before calling some
cpu-specific opcode, which also has some performance cost), there's
still some window where the application might not yet recognize the
change. So either we need some explicit migration points (where app
tells, please let me finish this func first) or transparent emulation.

Damn, how could the cpu designers come up with such weird concepts
in the first place ? :o


--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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help