From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030401AbdIZIjj (ORCPT ); Tue, 26 Sep 2017 04:39:39 -0400 Received: from terminus.zytor.com ([65.50.211.136]:33755 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965366AbdIZIjg (ORCPT ); Tue, 26 Sep 2017 04:39:36 -0400 Date: Tue, 26 Sep 2017 01:32:52 -0700 From: tip-bot for Ingo Molnar Message-ID: Cc: akpm@linux-foundation.org, fenghua.yu@intel.com, riel@redhat.com, yu-cheng.yu@intel.com, linux-kernel@vger.kernel.org, oleg@redhat.com, peterz@infradead.org, mingo@kernel.org, dave.hansen@linux.intel.com, ebiggers3@gmail.com, luto@amacapital.net, bp@alien8.de, torvalds@linux-foundation.org, tglx@linutronix.de, hpa@zytor.com Reply-To: bp@alien8.de, luto@amacapital.net, ebiggers3@gmail.com, dave.hansen@linux.intel.com, tglx@linutronix.de, hpa@zytor.com, torvalds@linux-foundation.org, fenghua.yu@intel.com, akpm@linux-foundation.org, mingo@kernel.org, peterz@infradead.org, linux-kernel@vger.kernel.org, oleg@redhat.com, riel@redhat.com, yu-cheng.yu@intel.com In-Reply-To: <20170923130016.21448-31-mingo@kernel.org> References: <20170923130016.21448-31-mingo@kernel.org> To: linux-tip-commits@vger.kernel.org Subject: [tip:x86/fpu] x86/fpu: Fix stale comments about lazy FPU logic Git-Commit-ID: 7f1487c59b7c6dcb20155f4302985da2659a2997 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 7f1487c59b7c6dcb20155f4302985da2659a2997 Gitweb: http://git.kernel.org/tip/7f1487c59b7c6dcb20155f4302985da2659a2997 Author: Ingo Molnar AuthorDate: Sat, 23 Sep 2017 15:00:13 +0200 Committer: Ingo Molnar CommitDate: Tue, 26 Sep 2017 09:43:43 +0200 x86/fpu: Fix stale comments about lazy FPU logic We don't do any lazy restore anymore, what we have are two pieces of optimization: - no-FPU tasks that don't save/restore the FPU context (kernel threads are such) - cached FPU registers maintained via the fpu->last_cpu field. This means that if an FPU task context switches to a non-FPU task then we can maintain the FPU registers as an in-FPU copies (cache), and skip the restoration of them once we switch back to the original FPU-using task. Update all the comments that still referred to old 'lazy' and 'unlazy' concepts. Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Dave Hansen Cc: Eric Biggers Cc: Fenghua Yu Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: Yu-cheng Yu Link: http://lkml.kernel.org/r/20170923130016.21448-31-mingo@kernel.org Signed-off-by: Ingo Molnar --- arch/x86/kernel/fpu/core.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index c8d6032..77668d9 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -205,9 +205,6 @@ int fpu__copy(struct fpu *dst_fpu, struct fpu *src_fpu) /* * Save current FPU registers directly into the child * FPU context, without any memory-to-memory copying. - * In lazy mode, if the FPU context isn't loaded into - * fpregs, CR0.TS will be set and do_device_not_available - * will load the FPU context. * * We have to do all this with preemption disabled, * mostly because of the FNSAVE case, because in that @@ -285,13 +282,13 @@ void fpu__activate_fpstate_read(struct fpu *fpu) /* * This function must be called before we write a task's fpstate. * - * If the task has used the FPU before then unlazy it. + * If the task has used the FPU before then invalidate any cached FPU registers. * If the task has not used the FPU before then initialize its fpstate. * * After this function call, after registers in the fpstate are * modified and the child task has woken up, the child task will * restore the modified FPU state from the modified context. If we - * didn't clear its lazy status here then the lazy in-registers + * didn't clear its cached status here then the cached in-registers * state pending on its former CPU could be restored, corrupting * the modifications. */ @@ -304,7 +301,7 @@ void fpu__activate_fpstate_write(struct fpu *fpu) WARN_ON_FPU(fpu == ¤t->thread.fpu); if (fpu->initialized) { - /* Invalidate any lazy state: */ + /* Invalidate any cached state: */ __fpu_invalidate_fpregs_state(fpu); } else { fpstate_init(&fpu->state);