All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Borislav Petkov <bp@alien8.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>,
	X86 ML <x86@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 2/5] x86/fpu: Fix FNSAVE usage in eagerfpu mode
Date: Mon, 25 Jan 2016 09:25:00 -0800	[thread overview]
Message-ID: <CALCETrVjt3qcbrBa5BQ36ieQtL=JCwy_0n1JvF+tvLV0FVE-wg@mail.gmail.com> (raw)
In-Reply-To: <56A641FC.1030302@linux.intel.com>

On Jan 25, 2016 7:41 AM, "Dave Hansen" <dave.hansen@linux.intel.com> wrote:
>
> On 01/24/2016 02:38 PM, Andy Lutomirski wrote:
> >       if (fpu->fpregs_active) {
> > +             /*
> > +              * Ignore return value -- we don't care if reg state
> > +              * is clobbered.
> > +              */
> >               copy_fpregs_to_fpstate(fpu);
> >       } else {
> >               this_cpu_write(fpu_fpregs_owner_ctx, NULL);
> > @@ -189,8 +193,12 @@ void fpu__save(struct fpu *fpu)
> >
> >       preempt_disable();
> >       if (fpu->fpregs_active) {
> > -             if (!copy_fpregs_to_fpstate(fpu))
> > -                     fpregs_deactivate(fpu);
> > +             if (!copy_fpregs_to_fpstate(fpu)) {
> > +                     if (use_eager_fpu())
> > +                             copy_kernel_to_fpregs(&fpu->state);
> > +                     else
> > +                             fpregs_deactivate(fpu);
> > +             }
> >       }
> >       preempt_enable();
>
> I wonder if we should just make the
>
> > +                     if (use_eager_fpu())
> > +                             copy_kernel_to_fpregs(&fpu->state);
> > +                     else
> > +                             fpregs_deactivate(fpu);
>
> behavior the default _inside_ copy_fpregs_to_fpstate(fpu).  We evidently
> got it wrong in 2/3 of the call sites that needed it.  It ends up being
> an optimization for FNSAVE (because it allows us to avoid an FRSTOR),
> but we only take advantage of that in cases of kernel_fpu_begin/end().
>
> FXSAVE has been around since at _least_ 1999, and I'd expect it to get
> used in place of FNSAVE everywhere that it is available.
>
> If we don't want to do that, maybe we should add a "clobber" argument to
> copy_fpregs_to_fpstate() for when it's allowed to clobber the register
> state.
>
> I just hate putting this logic at all the call sites.

Me too.  I was thinking about having a clobber and a non-clobber variant.
The tricky part is that we have to think about preemption, too.  In
theory, copying fpregs to somewhere other then the normal spot can be
okay with preemption on except in the FNSAVE case, but all the callers
probably need preemption off anyway.

Even if we do the cleanup, I think I'd rather fix the bug in place
first so the diff is clearer and then clean it up on top of that.

Does that seem reasonable?


--Andy

  reply	other threads:[~2016-01-25 17:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-24 22:38 [PATCH v2 0/5] x86/fpu: eagerfpu fixes, speedups, and default enablement Andy Lutomirski
2016-01-24 22:38 ` [PATCH v2 1/5] x86/fpu: Fix math emulation in eager fpu mode Andy Lutomirski
2016-02-09 16:10   ` [tip:x86/fpu] " tip-bot for Andy Lutomirski
2016-01-24 22:38 ` [PATCH v2 2/5] x86/fpu: Fix FNSAVE usage in eagerfpu mode Andy Lutomirski
2016-01-25 15:40   ` Dave Hansen
2016-01-25 17:25     ` Andy Lutomirski [this message]
2016-01-25 17:26       ` Dave Hansen
2016-02-09 16:10   ` [tip:x86/fpu] " tip-bot for Andy Lutomirski
2016-01-24 22:38 ` [PATCH v2 3/5] x86/fpu: Fold fpu_copy into fpu__copy Andy Lutomirski
2016-02-09 16:10   ` [tip:x86/fpu] x86/fpu: Fold fpu_copy() into fpu__copy() tip-bot for Andy Lutomirski
2016-01-24 22:38 ` [PATCH v2 4/5] x86/fpu: Speed up lazy FPU restores slightly Andy Lutomirski
2016-02-09 16:11   ` [tip:x86/fpu] " tip-bot for Andy Lutomirski
2016-01-24 22:38 ` [PATCH v2 5/5] x86/fpu: Default eagerfpu=on on all CPUs Andy Lutomirski
2016-02-09 16:11   ` [tip:x86/fpu] " tip-bot for Andy Lutomirski

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='CALCETrVjt3qcbrBa5BQ36ieQtL=JCwy_0n1JvF+tvLV0FVE-wg@mail.gmail.com' \
    --to=luto@amacapital.net \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=sai.praneeth.prakhya@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.