From: Rik van Riel <riel@surriel.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
"Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Andrew Lutomirski <luto@kernel.org>,
dave.hansen@linux.intel.com, LKML <linux-kernel@vger.kernel.org>,
X86 ML <x86@kernel.org>
Subject: Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch
Date: Wed, 11 Jul 2018 16:10:33 -0400 [thread overview]
Message-ID: <1531339833.26425.1.camel@surriel.com> (raw)
In-Reply-To: <20180711162850.52jmzsuwegpk7rag@breakpoint.cc>
[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]
On Wed, 2018-07-11 at 18:28 +0200, Sebastian Andrzej Siewior wrote:
> On 2018-06-15 22:33:47 [+0200], Jason A. Donenfeld wrote:
> > On Fri, Jun 15, 2018 at 8:32 PM Andy Lutomirski <luto@kernel.org>
> > wrote:
> > > quite in the form you imagined. The idea that we've tossed
> > > around is
> > > to restore FPU state on return to user mode. Roughly, we'd
> > > introduce
> > > a new thread flag TIF_FPU_UNLOADED (name TBD).
> > > prepare_exit_to_usermode() would notice this flag, copy the
> > > fpstate to
> > > fpregs, and clear the flag. (Or maybe exit_to_usermode_loop() --
> > > No
> > > one has quite thought it through, but I think it should be
> > > outside the
> > > loop.) We'd update all the FPU accessors to understand the flag.
> >
> > Yes! This is exactly what I was thinking. Then those calls to
> > begin()
> > and end() could be placed as close to the actual FPU usage as
> > possible.
>
> I was thinking about this myself. Did anyone try to hack something in
> the meantime? I might want to look into this, too :)
I have implemented this before, back before the
big rewrite of the syscall entry and exit code.
It seemed to work fine.
--
All Rights Reversed.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2018-07-11 20:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-15 13:11 Lazy FPU restoration / moving kernel_fpu_end() to context switch Jason A. Donenfeld
2018-06-15 16:25 ` Thomas Gleixner
2018-06-15 18:33 ` Brian Gerst
2018-06-15 19:34 ` Peter Zijlstra
2018-06-15 20:30 ` Jason A. Donenfeld
2018-06-18 9:44 ` Peter Zijlstra
2018-06-18 15:25 ` Jason A. Donenfeld
2018-06-15 18:31 ` Andy Lutomirski
2018-06-15 18:40 ` Rik van Riel
2018-06-15 18:41 ` Dave Hansen
2018-06-15 18:49 ` Andy Lutomirski
2018-06-15 18:48 ` Dave Hansen
2018-06-15 18:53 ` Andy Lutomirski
2018-06-15 20:27 ` Jason A. Donenfeld
2018-06-15 20:48 ` Jason A. Donenfeld
2018-06-19 11:43 ` David Laight
2018-06-19 13:08 ` Thomas Gleixner
2018-06-15 20:33 ` Jason A. Donenfeld
2018-06-15 20:42 ` Dave Hansen
2018-06-15 20:52 ` Andy Lutomirski
2018-06-15 20:56 ` Rik van Riel
2018-07-11 16:28 ` Sebastian Andrzej Siewior
2018-07-11 20:10 ` Rik van Riel [this message]
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=1531339833.26425.1.camel@surriel.com \
--to=riel@surriel.com \
--cc=Jason@zx2c4.com \
--cc=bigeasy@linutronix.de \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--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 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.