Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1495954
| From | Paolo Bonzini <pbonzini@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode |
| Date | 2016-10-05 18:20 +0200 |
| Message-ID | <soX5f-3e7-9@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <soIpz-1De-13@gated-at.bofh.it> <soOEG-604-15@gated-at.bofh.it> <soUTL-1HA-1@gated-at.bofh.it> <soV3s-209-5@gated-at.bofh.it> <soWVz-3as-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 05/10/2016 17:59, Andy Lutomirski wrote: > I actually benchmarked the underlying instructions quite a bit on > Intel. (Not on AMD, but I doubt the results are very different.) > Writes to CR0.TS are *incredibly* slow, as are device-not-available > exceptions. Keep in mind that, while there's a (slow) CLTS > instruction, there is no corresponding STTS instruction, so we're left > with a fully serializing, slowly microcoded move to CR0. On SVM, I > think it's worse, because IIRC SVM doesn't have fancy execution > controls that let MOV to CR0 avoid exiting. SVM lets you choose whether to trap on TS and MP; update_cr0_intercept is where KVM does that (the "selective CR0 write" intercept is always on, while the "CR0 write" intercept is toggled in that function). > We're talking a couple > hundred cycles best case for a TS set/clear pair, and thousands of > cycles if we actually take a fault. > > In contrast, an unconditional XSAVE + XRSTOR was considerably faster. Did you also do a comparison against FXSAVE/FXRSTOR (on either pre- or post-SandyBridge processors)? But yeah, it's possible that the lack of STTS screws the whole plan, despite the fpu.preload optimization in switch_fpu_prepare. Paolo > This leads to the counterintuitive result that, if we switch from task > A to B and back and task A is heavily using the FPU, then it's faster > to unconditoinally save and restore the full state both ways than it > is to set and clear TS so we can avoid it.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode riel@redhat.com - 2016-10-05 02:40 +0200
Re: [PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode Paolo Bonzini <pbonzini@redhat.com> - 2016-10-05 09:20 +0200
Re: [PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode Rik van Riel <riel@redhat.com> - 2016-10-05 16:00 +0200
Re: [PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode Paolo Bonzini <pbonzini@redhat.com> - 2016-10-05 16:10 +0200
Re: [PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode Andy Lutomirski <luto@amacapital.net> - 2016-10-05 18:10 +0200
Re: [PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode Paolo Bonzini <pbonzini@redhat.com> - 2016-10-05 18:20 +0200
[tip:x86/fpu] x86/fpu: Hard-disable lazy FPU mode tip-bot for Andy Lutomirski <tipbot@zytor.com> - 2016-10-07 11:50 +0200
csiph-web