On Fri, May 25, 2018 at 11:04:03AM +0100, Alex Bennée wrote: > > Dave Martin <Dave.Martin@xxxxxxx> writes: > > > Currently the FPSIMD handling code uses the condition task->mm == > > NULL as a hint that task has no FPSIMD register context. > > > > The ->mm check is only there to filter out tasks that cannot > > possibly have FPSIMD context loaded, for optimisation purposes. > > Also, TIF_FOREIGN_FPSTATE must always be checked anyway before > > saving FPSIMD context back to memory. For these reasons, the ->mm > > checks are not useful, providing that TIF_FOREIGN_FPSTATE is > > maintained in a consistent way for all threads. > > > > The context switch logic is already deliberately optimised to defer > > reloads of the regs until ret_to_user (or sigreturn as a special > > case), and save them only if they have been previously loaded. > > These paths are the only places where the wrong_task and wrong_cpu > > conditions can be made false, by calling fpsimd_bind_task_to_cpu(). > > Kernel threads by definition never reach these paths. As a result, > > the wrong_task and wrong_cpu tests in fpsimd_thread_switch() will > > always yield true for kernel threads. > > > > This patch removes the redundant checks and special-case code, ensuring that TIF_FOREIGN_FPSTATE is set whenever a kernel thread is scheduled in, and ensures that this flag is set for the init > > task. The fpsimd_flush_task_state() call already present in > > copy_thread() ensures the same for any new task. > > > > With TIF_FOREIGN_FPSTATE always set for kernel threads, this patch > > ensures that no extra context save work is added for kernel > > threads, and eliminates the redundant context saving that may > > currently occur for kernel threads that have acquired an mm via > > use_mm(). > > > > Signed-off-by: Dave Martin <Dave.Martin@xxxxxxx> > > Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx> > > Reviewed-by: Alex Bennée <alex.bennee@xxxxxxxxxx> > > Still good (although obviously without the ws damage in the commit). Agreed -- I'll coordinate with Marc to make sure that gets fixed. Thanks for the review. [...] Cheers ---Dave _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
