Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: Candidate Linux ABI for Intel AMX and hypothetical new related features | Date | Fri, 07 May 2021 21:22:18 +0200 |
| |
On Fri, May 07 2021 at 11:50, Andy Lutomirski wrote:
> On Fri, May 7, 2021 at 11:44 AM Thomas Gleixner <tglx@linutronix.de> wrote: >> >> On Mon, May 03 2021 at 06:43, Dave Hansen wrote: >> > On 5/2/21 10:18 PM, Florian Weimer wrote: >> >>> 5. If the feature is enabled in XCR0, the user happily uses it. >> >>> >> >>> For AMX, Linux implements "transparent first use" >> >>> so that it doesn't have to allocate 8KB context switch >> >>> buffers for tasks that don't actually use AMX. >> >>> It does this by arming XFD for all tasks, and taking a #NM >> >>> to allocate a context switch buffer only for those tasks >> >>> that actually execute AMX instructions. >> >> What happens if the kernel cannot allocate that additional context >> >> switch buffer? >> > >> > Well, it's vmalloc()'d and currently smaller that the kernel stack, >> > which is also vmalloc()'d. While it can theoretically fail, if it >> > happens you have bigger problems on your hands. >> >> Such a buffer allocation might also exceed a per process/cgroup >> limitation. Anything else which is accounted happens in syscall context >> which then returns an error on which the application can react. >> >> So what's the consequence when the allocation fails? Kill it right away >> from #NM? Kill it on the first signal? Do nothing and see what happens? >> > It has to be an immediate signal or kill.
Killing it right there is the only sensible thing to do.
> A failure to load FPU state is somewhat tolerable (and has to be for > CET), but a failure to *save* FPU state on a context switch would be a > really nasty can of worms.
:)
> At the very least we will want arch_prctl(ARCH_ALLOCTE_XSTATE, mask) > to allow HPC workloads to manually allocate the state and get an error > code if it fails.
Yes.
Thanks,
tglx
| |