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
--
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