Of course, if we are really doing all eager fpu, we could just leave cr0.ts always clear and not touch it at all... On February 1, 2014 11:46:15 AM PST, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >On Sat, Feb 1, 2014 at 11:35 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> >> This will obviously not protect eageronly features (MPX, LWP, ...) so >this >> means those features are permanently unavailable to the kernel, even >inside >> kernel_fpu_begin/end. Now, currently I don't think we have any plans >to use >> those in the kernel (at least not in a way where kernel_fpu_begin/end >makes >> sense as bracketing), but it is something worth keeping in mind. > >Hmm. If there are features that (silently) depend on the FPU state >being on, then the plain "stts" doesn't work at all, because we'd be >returning to user space too (not just kernel space) with TS turned >off. > >.. which *does* actually bring up something that might work, and might >be a good idea: remove the "restore math state or set TS" from the >normal kernel paths *entirely*, and move it to the "return to user >space" phase. > >We could do that with the whole "task_work" thing (or perhaps just >do_notify_resume(), especially after merging the "don't necessarily >return with iret" patch I sent out earlier), with additionally making >sure that scheduling does the right thing wrt a "currently dirty math >state due to kernel use". > >The advantage of that would be that we really could do a *lot* of FP >math very cheaply in the kernel, because we'd pay the overhead of >kernel_fpu_begin/end() just once (well, the "end" part would be just >setting the bit that we now have dirty state, the cost would be in the >return-to-user-space-and-restore-fp-state part). > >Comments? That would be much more invasive than just changing >__kernel_fpu_end(), but would bring in possibly quite noticeable >advantages under loads that use the FP/vector resources in the kernel. > > Linus -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html