Re: [PATCH] Make math_state_restore() save and restore the interrupt flag

[H. Peter Anvin]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/