public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andy Lutomirski' <luto@kernel.org>, "x86@kernel.org" <x86@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Krzysztof Mazur" <krzysiek@podlesie.net>,
	"Krzysztof Olędzki" <ole@ans.pl>, "Arnd Bergmann" <arnd@arndb.de>
Subject: RE: [PATCH 1/4] x86/fpu: Add kernel_fpu_begin_mask() to selectively initialize state
Date: Mon, 18 Jan 2021 14:03:07 +0000	[thread overview]
Message-ID: <71144eab31a34dc7add39655a289f8a8@AcuMS.aculab.com> (raw)
In-Reply-To: <a9630f17c5bcafbfe297a0828c7b6c78b0f6dcbe.1610950681.git.luto@kernel.org>

From: Andy Lutomirski
> Sent: 18 January 2021 06:21
> 
> Currently, requesting kernel FPU access doesn't distinguish which parts of
> the extended ("FPU") state are needed.  This is nice for simplicity, but
> there are a few cases in which it's suboptimal:
> 
>  - The vast majority of in-kernel FPU users want XMM/YMM/ZMM state but do
>    not use legacy 387 state.  These users want MXCSR initialized but don't
>    care about the FPU control word.  Skipping FNINIT would save time.
>    (Empirically, FNINIT is several times slower than LDMXCSR.)
> 
>  - Code that wants MMX doesn't want need MXCSR or FCW initialized.
>    _mmx_memcpy(), for example, can run before CR4.OSFXSR gets set, and
>    initializing MXCSR will fail.
> 
>  - Any future in-kernel users of XFD (eXtended Feature Disable)-capable
>    dynamic states will need special handling.
> 
> This patch adds a more specific API that allows callers specify exactly
> what they want.

Is it worth returning whether the required fpu feature is available?
Or, maybe optionally, available cheaply?

There are also code fragments that really just want one or two
[xyx]mm registers to speed something up.
For instance PCIe reads can be a lot faster if a wide register
can be used.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  parent reply	other threads:[~2021-01-18 14:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18  6:20 [PATCH 0/4] x86/fpu: Reduce unnecessary FNINIT and MXCSR usage Andy Lutomirski
2021-01-18  6:20 ` [PATCH 1/4] x86/fpu: Add kernel_fpu_begin_mask() to selectively initialize state Andy Lutomirski
2021-01-18 12:21   ` Peter Zijlstra
2021-01-18 14:03   ` David Laight [this message]
2021-01-19 11:08   ` Borislav Petkov
2021-01-18  6:20 ` [PATCH 2/4] x86/mmx: Use KFPU_MMX for MMX string operations Andy Lutomirski
2021-01-18  6:20 ` [PATCH 3/4] x86/fpu: Make the EFI FPU calling convention explicit Andy Lutomirski
2021-01-18 12:13   ` Borislav Petkov
2021-01-18  6:20 ` [PATCH 4/4] x86/fpu/64: Don't FNINIT in kernel_fpu_begin() Andy Lutomirski
2021-01-18  8:25 ` [PATCH 0/4] x86/fpu: Reduce unnecessary FNINIT and MXCSR usage Krzysztof Olędzki

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=71144eab31a34dc7add39655a289f8a8@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=arnd@arndb.de \
    --cc=krzysiek@podlesie.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=ole@ans.pl \
    --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