linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Tony Luck <tony.luck@intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Rik van Riel <riel@surriel.com>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 8/8] x86/fpu/xstate: Restore supervisor xstates for __fpu__restore_sig()
Date: Mon, 02 Mar 2020 10:09:19 -0800	[thread overview]
Message-ID: <6778d141a3cdbbe51cdeb3a8efb9c34e0951f6c6.camel@intel.com> (raw)
In-Reply-To: <20200229143644.GA1129@zn.tnic>

On Sat, 2020-02-29 at 15:36 +0100, Borislav Petkov wrote:
> On Fri, Feb 28, 2020 at 02:13:29PM -0800, Yu-cheng Yu wrote:
> > If the XSAVES buffer already has current data (i.e. TIF_NEED_FPU_LOAD is
> > set), then skip copy_xregs_to_kernel().  This happens when the task was
> > context-switched out and has not returned to user-mode.
> 
> So I got tired of this peacemeal game back'n'forth and went and did your
> work for ya.
> 
> First of all, on my fairly new KBL test box, the context size is almost
> a kB:
> 
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
> [    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [    0.000000] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
> [    0.000000] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
> [    0.000000] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.
> 
> Then, I added this ontop of your patchset:
> 
> diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
> index 0d3e06a772b0..2e57b8d79c0e 100644
> --- a/arch/x86/kernel/fpu/signal.c
> +++ b/arch/x86/kernel/fpu/signal.c
> @@ -337,6 +337,8 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size)
>          */
>         fpregs_lock();
>         if (!test_thread_flag(TIF_NEED_FPU_LOAD)) {
> +               trace_printk("!NEED_FPU_LOAD, size: %d, supervisor: 0x%llx\n",
> +                            size, xfeatures_mask_supervisor());
>                 if (xfeatures_mask_supervisor())
>                         copy_xregs_to_kernel(&fpu->state.xsave);
>                 set_thread_flag(TIF_NEED_FPU_LOAD);
> 
> and traced a fairly boring kernel build workload where the kernel
> .config is not even a distro one but a tailored for this machine.
> 
> Which means, it took 3m35.058s to build and the trace buffer had 53973
> entries like this one:
> 
> bash-1211  [002] ...1   648.238585: __fpu__restore_sig: !NEED_FPU_LOAD, size: 1092, supervisor: 0x0
> 
> which means I have
> 
> 53973 / (3*60 + 35) =~ 251 XSAVES invocations per second!
> 
> And this only during this single workload - I don't even wanna imagine
> what that number would be if it were a huge, overloaded box with a
> signal heavy workload.
> 
> And all this overhead to save 16 + 24 bytes supervisor states and throw
> away the rest up to 960 bytes each time.
> 
> Err, I don't think so.

This patch serves supervisor states that has not been saved prior to
sigreturn.  CET state is in sigcontext and does not need to be saved here.

We can drop this for now, and for new supervisor states, replace
copy_xregs_to_kernel() with a callback that saves only necessary
information.

I will send out v3.

Yu-cheng



  reply	other threads:[~2020-03-02 18:10 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21 20:18 [PATCH v2 0/8] Support XSAVES supervisor states Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 1/8] x86/fpu/xstate: Define new macros for supervisor and user xstates Yu-cheng Yu
2020-02-20 11:47   ` Borislav Petkov
2020-02-20 20:23     ` Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 2/8] x86/fpu/xstate: Separate user and supervisor xfeatures mask Yu-cheng Yu
2020-02-21 10:34   ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 3/8] x86/fpu/xstate: Introduce XSAVES supervisor states Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 4/8] x86/fpu/xstate: Define new functions for clearing fpregs and xstates Yu-cheng Yu
2020-02-21 14:04   ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 5/8] x86/fpu/xstate: Rename validate_xstate_header() to validate_xstate_header_from_user() Yu-cheng Yu
2020-02-21 14:13   ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 6/8] x86/fpu/xstate: Update sanitize_restored_xstate() for supervisor xstates Yu-cheng Yu
2020-02-21 14:30   ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 7/8] x86/fpu/xstate: Update copy_kernel_to_xregs_err() for XSAVES supervisor states Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 8/8] x86/fpu/xstate: Restore supervisor xstates for __fpu__restore_sig() Yu-cheng Yu
2020-02-21 17:58   ` Borislav Petkov
2020-02-27 22:52     ` Yu-cheng Yu
2020-02-28 12:17       ` Borislav Petkov
2020-02-28 12:51         ` Sebastian Andrzej Siewior
2020-02-28 15:53         ` Yu-cheng Yu
2020-02-28 16:23           ` Borislav Petkov
2020-02-28 16:20             ` Yu-cheng Yu
2020-02-28 16:50               ` Sebastian Andrzej Siewior
2020-02-28 16:54                 ` Yu-cheng Yu
2020-02-28 17:22               ` Borislav Petkov
2020-02-28 18:11                 ` Yu-cheng Yu
2020-02-28 18:31                   ` Borislav Petkov
2020-02-28 21:22                     ` Yu-cheng Yu
2020-02-28 21:47                       ` Borislav Petkov
2020-02-28 22:13                         ` Yu-cheng Yu
2020-02-29 14:36                           ` Borislav Petkov
2020-03-02 18:09                             ` Yu-cheng Yu [this message]
2020-03-04 18:18                               ` Yu-cheng Yu
2020-03-06 20:50                                 ` Borislav Petkov
2020-03-10 20:36                                   ` Yu-cheng Yu
2020-03-10 21:16                                     ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6778d141a3cdbbe51cdeb3a8efb9c34e0951f6c6.camel@intel.com \
    --to=yu-cheng.yu@intel.com \
    --cc=bigeasy@linutronix.de \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=riel@surriel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).