On Wed, 5 Mar 2025 18:37:25 +0100 Ingo Molnar <mingo@xxxxxxxxxx> wrote: > * Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > > On 3/5/25 01:07, Ingo Molnar wrote:>> Alternatives considered: > > >> - Make kernel-mode FPU sections fully preemptible. This would require > > >> growing task_struct by another struct fpstate which is more than 2K. > > > > > > So that's something that will probably happen once the kernel is built > > > using APX anyway? > > > > I was expecting that building the kernel with APX would be very > > different than a kernel_fpu_begin(). We don't just need *one* more > > save area for APX registers: we need a stack, just like normal GPRs. > > Yes - but my point is: with any APX build we'd probably be saving > FPU(-ish) registers at entry points, into a separate context area. If > that includes FPU registers then we'd not have to do > kernel_fpu_begin()/end(). Since the registers are caller saved (like the SSE onwards ones) none of them really need to be saved on syscall entry (just zeroed on return). They do need saving on interrupt entry. For some unknown reason the kernel saves the xyzmm ones on syscall entry. For normal programs they won't be live - because of the asm syscall wrapper is called from C. So I think they can only be live if a system call is directly inlined into the C function. Just marking them all 'clobbered' would have done. But it now all too late to change. David > > In other words, we'd be doing something close to 'growing task_struct > by another struct fpstate', or so - regardless of whether it's in > task_struct or some sort of extended pt_regs. The kernel would also be > close to 'FPU-safe', i.e. there likely wouldn't be a need for > kernel_fpu_begin()/end(). > > Thanks, > > Ingo >
