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

3 messages, 3 authors, 2021-05-21 · 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-05-17 09:57:18

* Thomas Gleixner:
Having a proper interface (syscall, prctl) which user space can use to
ask for permission and allocation of the necessary buffer(s) is clearly
avoiding the downsides and provides the necessary mechanisms for proper
control and failure handling.

It's not the end of the world if something which wants to utilize this
has do issue a syscall during detection. It does not matter whether
that's a library or just the application code itself.

That's a one off operation and every involved entity can cache the
result in TLS.
I'm not sure if it's a good idea to have each AMX consumer to set up its
own TLS cache.  How expensive is checking XCR0 via XGETBV instead on the
AMX path?  Then AMX can be enabled on the thread via a system call.  It
also allows disabling of AMX.

It would also need an AT_HWCAP2 feature flag telling user space that AMX
support is available after that system call (switching on AMX to check
whether AMX paths should enabled later seems potentially wasteful if the
AMX paths are never taken after all).

Thanks,
Florian

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

From: Thomas Gleixner <hidden>
Date: 2021-05-17 10:18:16

On Mon, May 17 2021 at 11:56, Florian Weimer wrote:
* Thomas Gleixner:
quoted
Having a proper interface (syscall, prctl) which user space can use to
ask for permission and allocation of the necessary buffer(s) is clearly
avoiding the downsides and provides the necessary mechanisms for proper
control and failure handling.

It's not the end of the world if something which wants to utilize this
has do issue a syscall during detection. It does not matter whether
that's a library or just the application code itself.

That's a one off operation and every involved entity can cache the
result in TLS.
I'm not sure if it's a good idea to have each AMX consumer to set up its
own TLS cache.  How expensive is checking XCR0 via XGETBV instead on the
AMX path?  Then AMX can be enabled on the thread via a system call. 
Right, did not think about that.
It also allows disabling of AMX.
That needs reference counting, but yes it's possible.
It would also need an AT_HWCAP2 feature flag telling user space that AMX
support is available after that system call (switching on AMX to check
whether AMX paths should enabled later seems potentially wasteful if the
AMX paths are never taken after all).
Either that or just have:

       prctl(PR_QUERY_XSTATE_FEATURES,....
       prctl(PR_ENABLE_XSTATE_FEATURES,....
       prctl(PR_DISABLE_XSTATE_FEATURES,....

Thanks,

        tglx

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

From: Len Brown <lenb@kernel.org>
Date: 2021-05-21 16:29:56

On Mon, May 17, 2021 at 5:56 AM Florian Weimer [off-list ref] wrote:
How expensive is checking XCR0 via XGETBV instead, on the AMX path?
XGETBV takes about the same number of cycles as RDTSC (ie. it is
relatively fast)

Len Brown, Intel Open Source Technology Center
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help