[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Apr 2019 07:26:37 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: David Laight <David.Laight@...lab.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Rik van Riel <riel@...riel.com>,
Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v9 00/27] x86: load FPU registers on return to userland
On Thu, Apr 4, 2019 at 7:14 AM Sebastian Andrzej Siewior
<bigeasy@...utronix.de> wrote:
>
> On 2019-04-04 14:01:43 [+0000], David Laight wrote:
> > From: Sebastian Andrzej Siewior
> > > Sent: 03 April 2019 17:41
> > ...
> > > To access the FPU registers in kernel we need:
> > > - disable preemption to avoid that the scheduler switches tasks. By
> > > doing so it would set TIF_NEED_FPU_LOAD and the FPU registers would be
> > > not valid.
> > > - disable BH because the softirq might use kernel_fpu_begin() and then
> > > set TIF_NEED_FPU_LOAD instead loading the FPU registers on completion.
> >
> > Is there a possible optimisation here for kernel threads?
> > Since there is no 'user FP state' the 'kernel FP state' can
> > be saved by a task switch or softirq.
>
> There is no such thing as "kernel FP state" that is saved.
>
I think that David was asking whether we could make kernel_fpu_begin()
regions sometimes be preemptible. The answer is presumably yes, but I
think that should be a separate effort, and it should be justified
with improved performance above and beyond what we get with Jason's
simd_get() stuff.
Powered by blists - more mailing lists