* Dave Hansen <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
