Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752796AbcJCUFG (ORCPT ); Mon, 3 Oct 2016 16:05:06 -0400 Received: from mga07.intel.com ([134.134.136.100]:40002 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752136AbcJCUE7 (ORCPT ); Mon, 3 Oct 2016 16:04:59 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,291,1473145200"; d="scan'208";a="1039821954" Subject: Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded To: riel@redhat.com, linux-kernel@vger.kernel.org References: <1475353895-22175-1-git-send-email-riel@redhat.com> <1475353895-22175-5-git-send-email-riel@redhat.com> Cc: x86@kernel.org, tglx@linutronix.de, pbonzini@redhat.com, mingo@redhat.com, luto@kernel.org, hpa@zytor.com, bp@suse.de From: Dave Hansen Message-ID: <57F2B9E9.7030806@linux.intel.com> Date: Mon, 3 Oct 2016 13:04:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1475353895-22175-5-git-send-email-riel@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 824 Lines: 22 On 10/01/2016 01:31 PM, riel@redhat.com wrote: > /* > + * Check whether an FPU's register set is still loaded in the CPU. > + */ > +static inline bool fpu_lazy_skip_restore(struct fpu *fpu) > +{ > + bool still_loaded = (fpu->fpstate_active && > + fpu->last_cpu == raw_smp_processor_id() && > + __this_cpu_read(fpu_fpregs_owner_ctx) == fpu); > + > + fpu->fpregs_active = still_loaded; > + return still_loaded; > +} I wonder if we should call this something more along the lines of fpregs_activate_fast(), which returns if it managed to do the activation fast or not. I _think_ that's more along the lines of what it is actually doing. The fact that it can be lazy is really an implementation detail. What are the preempt rules with this thing? This needs to be called in preempt-disabled contexts, right?