Messages in this thread | | | Date | Thu, 28 May 2015 17:01:14 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 02/19] x86, fpu: Wrap get_xsave_addr() to make it safer |
| |
* Dave Hansen <dave@sr71.net> wrote:
> On 05/28/2015 01:41 AM, Ingo Molnar wrote: > > > What you want here is to make the (in-memory) FPU state valid and current, > > before reading it, and the function to use for that is > > fpu__activate_fpstate_read() (available in the latest tip:x86/fpu tree). > > Do we really want to unconditionally activate the FPU? > > Let's say supporting MPX didn't require eager mode and someone called > get_xsave_addr(). We would ideally want to keep the FPU inactive and just > return NULL. Right?
So there's two distinct types of 'active' here:
- active fpstate (in-kernel memory context buffer) - active fpregs (in-FPU hardware registers)
fpu__activate_fpstate_read() will only activate the fpstate for reads (as the name suggests it).
In your hypothetical case, if it's called with lazy FPU state then the fpstate is active already, and the fpstate represents the 'real' FPU state of the current task - while the FPU's contents are still some previous task's FPU state. So we can return the contents of this task's fpstate just fine even if the registers themselves are not (yet) loaded with them.
But the real question is: can we support in-use MPX with asynchronous lazy restore, while it's still semantically correct? I don't think so, unless you add MPX specific synchronous restore to the context switch path, which isn't such a good idea IMHO.
Furthermore, I don't think we want to extend lazy FPU use, in fact I'm considering getting rid of it altogether, even on old CPUs: the CR0 fault costs are horrible all across the CPU spectrum (even for legacy CPUs), and modern user-space makes use of the FPU all the time.
Yes, on older CPUs, if user-space does not use the FPU but context switches frequently, then the cost of always doing FPU save/restore is measurable, but the worst-case I've measured was something like a 10% increase in context switching cost.
Thanks,
Ingo
| |