lkml.org 
[lkml]   [2015]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2015-05-28 17:21    [W:0.100 / U:1.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site