From: Thiago Macieira <thiago.macieira@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: <fweimer@redhat.com>,
"Enrico Weigelt, metux IT consult" <lkml@metux.net>,
<hjl.tools@gmail.com>, <libc-alpha@sourceware.org>,
<linux-api@vger.kernel.org>, <linux-arch@vger.kernel.org>,
<x86@kernel.org>
Subject: Re: x86 CPU features detection for applications (and AMX)
Date: Mon, 28 Jun 2021 10:23:47 -0700 [thread overview]
Message-ID: <7968759.t5oPhm3B3B@tjmaciei-mobl1> (raw)
In-Reply-To: <20210628171115.GA13401@worktop.programming.kicks-ass.net>
On Monday, 28 June 2021 10:11:16 PDT Peter Zijlstra wrote:
> > Consequence: CPU feature checking is done *very* early, often before
> > main().
> For the linker based ones, yes. IIRC the ifunc() attribute is
> particularly useful here.
Exactly. ifunc was designed for this exact purpose. And hence the fact that
CPUID initialisation will be done very, very early.
Anyway, if the AMX state is a sticky "set once per process", it's likely going
to get set early for every process that *may* use AMX. And this is assuming we
do the library right and only set it if has AMX code at all, instead of all
the time.
On the other hand, if it's not set once and for all, we'll have to contend
with the size changing. TBH, this is a lot more complicated to deal with. Take
the hypothetical example of a preemptive user-space task scheduler that
interrupts an AMX routine (let's say for the sake of the argument that it is
an on-stack signal; I don't see why a scheduler would need to be alt-stack).
It will record the state and then transition to another routine. And this
routine may be resumed in another thread of the same process.
Will the kernel understand that the new routine does not need the AMX state?
Will it understand that the *other* routine, in the other thread will? If this
is not done automatically by the kernel, then the task scheduler will need to
know to ask the kernel what the reference count for the AMX state is and will
need a syscall to set it (not just increment/decrement, though one could
implement that with a loop).
This applies differently in the case of cooperative scheduling. The SysV ABI
will probably say that the AMX state is caller-save, so the function call from
the AMX-using routine implies all its state has been saved somewhere. But what
about the kernel-side AMX refcount? Is that part of the ABI?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
next prev parent reply other threads:[~2021-06-28 17:23 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-23 15:04 x86 CPU features detection for applications (and AMX) Florian Weimer
2021-06-23 15:32 ` Dave Hansen
2021-07-08 6:05 ` Florian Weimer
2021-07-08 14:19 ` Dave Hansen
2021-07-08 14:31 ` Florian Weimer
2021-07-08 14:36 ` Dave Hansen
2021-07-08 14:41 ` Florian Weimer
2021-06-25 23:31 ` Thiago Macieira
2021-06-28 12:40 ` Enrico Weigelt, metux IT consult
2021-06-28 13:20 ` Peter Zijlstra
2021-06-30 12:50 ` Enrico Weigelt, metux IT consult
2021-06-30 15:36 ` Thiago Macieira
2021-07-01 7:35 ` Enrico Weigelt, metux IT consult
2021-06-28 15:08 ` Thiago Macieira
2021-06-28 15:27 ` Peter Zijlstra
2021-06-28 16:13 ` Thiago Macieira
2021-06-28 17:11 ` Peter Zijlstra
2021-06-28 17:23 ` Thiago Macieira [this message]
2021-06-28 19:08 ` Peter Zijlstra
2021-06-28 19:26 ` Thiago Macieira
2021-06-28 17:43 ` Peter Zijlstra
2021-06-28 19:05 ` Thiago Macieira
2021-06-30 14:32 ` Enrico Weigelt, metux IT consult
2021-06-30 14:34 ` Florian Weimer
2021-06-30 15:16 ` Enrico Weigelt, metux IT consult
2021-06-30 15:38 ` Florian Weimer
2021-07-01 8:08 ` Enrico Weigelt, metux IT consult
2021-07-01 8:21 ` Florian Weimer
2021-07-01 11:59 ` Enrico Weigelt, metux IT consult
2021-07-06 12:57 ` Florian Weimer
2021-06-30 15:29 ` Thiago Macieira
2021-07-01 11:57 ` Enrico Weigelt, metux IT consult
2021-07-08 7:08 ` Florian Weimer
2021-07-08 15:13 ` Thiago Macieira
2021-07-08 17:56 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7968759.t5oPhm3B3B@tjmaciei-mobl1 \
--to=thiago.macieira@intel.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=lkml@metux.net \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.