On Fri, May 25, 2018 at 11:04:03AM +0100, Alex Bennée wrote: > > Dave Martin <dave.mar...@arm.com> 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.mar...@arm.com> > > Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> > > Reviewed-by: Alex Bennée <alex.ben...@linaro.org> > > 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@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
