[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <71144eab31a34dc7add39655a289f8a8@AcuMS.aculab.com>
Date: Mon, 18 Jan 2021 14:03:07 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Andy Lutomirski' <luto@...nel.org>,
"x86@...nel.org" <x86@...nel.org>
CC: LKML <linux-kernel@...r.kernel.org>,
Krzysztof Mazur <krzysiek@...lesie.net>,
Krzysztof Olędzki <ole@....pl>,
Arnd Bergmann <arnd@...db.de>
Subject: RE: [PATCH 1/4] x86/fpu: Add kernel_fpu_begin_mask() to selectively
initialize state
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)
Powered by blists - more mailing lists