Re: [RFC PATCH 04/11] x86,fpu: defer FPU restore until return to userspace

[Rik van Riel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2015 12:18 PM, Andy Lutomirski wrote:
> On Tue, Jan 13, 2015 at 9:11 AM, Oleg Nesterov <oleg@xxxxxxxxxx>
> wrote:
>> On 01/11, riel@xxxxxxxxxx wrote:
>>> 
>>> Defer restoring the FPU state, if so desired, until the task
>>> returns to userspace.
>> 
>> And I have another concern.
>> 
>> Afaocs with this patch the idle threads will run with
>> TIF_LOAD_FPU set but without fpu.has_fpu.
> 
> Yuck.  IMO there are still too many possible states.
> 
> AFAICS the sensible states for a task are:
> 
> - Task is current on some cpu and FPU is loaded into that cpu. -
> Task is current on some cpu and FPU is in memory. - Task is current
> on some cpu and FPU is loaded into a different cpu.

When switching a task out, in prepare_fpu_switch() we will always save
the FPU state to memory. The third case can be treated identical to the
second case.

> - Task is not current and FPU is in memory. - Task is not current
> and FPU is loaded into some cpu.

Same for this one. When the task is not current, the FPU state
will have been saved to memory. If we try running the task
somewhere else, it devolves to "FPU is in memory".

> Am I missing anything?  (In lazy mode, there are a few more
> involving CR0.TS.)
> 
> That's five states, plus an optional cpu number.  But we have tons
> of state variable that can express all kinds of nonsense things.
> 
> If we asserted that we were in a sensible state and fixed the
> things that exited the sensible states, maybe this would be easier
> to understand and debug.

Lets see what things we could test, at different points.

1) At context switch time, we need to make sure that the previous task
   will no longer have __thread_has_fpu()

2) When loading the FPU state, we need to make sure that the current
   task does not have __thread_has_fpu()

3) ... what else?

- -- 
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUtVmPAAoJEM553pKExN6Dc0gIAI0JZE4VpNlJElnuGbFKzM8t
r9dSH3XLeEX5/JARsQMNuwUL7HjjBbYO9PrdpejVAEUq2XltVyq3+RuSYMBprlpV
aCWKrw9jn7H43++LSziXh0LP+t+zqL9+/5WUm3oVWkTXJEBu9CdNgYYP7luf87nX
+mxqDsp5YjmmYJRW2LncK/SuEpItTAtHI5bORjsbWNQOZ2pl31cr1ZEbdrRaZqje
5wONfs0f2mor0Ms7FSzVJCNmps3TGJnfpkx37vzqRiPkisdWVcM16RwvM6jJTFZ+
VmM2Jj4xWMhPYvqpZ8oZWAb8xNCl+DijjZFEGW1j9Ji5gcPQ2HLvFEWNp3TpIeM=
=OU/0
-----END PGP SIGNATURE-----
--
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/