-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/13/2015 12:57 PM, Andy Lutomirski wrote: > On Tue, Jan 13, 2015 at 9:44 AM, Rik van Riel <[email protected]> > wrote: On 01/13/2015 12:18 PM, Andy Lutomirski wrote:
>>>> - 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". > > > Isn't there a case where the FPU is in memory *and* in the cpu > regs? Isn't that how you can skip reloading the FPU after going > idle and returning? Is this what fpu_lazy_restore is for? > Confused. Indeed, if we end up running the task on the same CPU again, and the FPU still has the state loaded, we may skip restoring the FPU state. >>>> 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() > >> Examples, any of which may be wrong: > >> If !current, then !TIF_LOAD_FPU We set TIF_LOAD_CPU on the next task at context switch time, which is different from the current task. I suspect we can deal with that exception, though :) What we can test is that "new" does not already have TIF_LOAD_CPU set... >> If switching out a task with TIF_LOAD_FPU set, then !has_fpu ... and that old does not have both TIF_LOAD_FPU and has_fpu. >> If last_cpu == smp_processor_id(), then fpu_owner == fpu. Not necessarily, since the task may not have entered userspace in a very long time, so it may not have loaded its FPU context. >> If has_fpu, then the task must be current somewhere and last_cpu >> must be the cpu on which it's current. Indeed, if has_fpu, then last_cpu must match the current cpu. - -- All rights reversed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUtWBOAAoJEM553pKExN6DNwIH/2wzfLqqM1V/Asd29nidDUrw zD7HN//LyWTLjNMfAS4M/rOk3LsbphFBOo2L5BE7CYoNAGEWwKcQi7ld3dDAXeZL +AkRtzMNEU1NqzrtnpGhABBrn3wBXwr9ldKSlaVQhYUop3q5Hhg8lyo2v+wWKf7y ULi/RLiERS72tUomFXTE4RT021N2h+tl42jSREEyT0+VqEc7vqTlb5fctsF3VAhS g48fX/VOYit3rXFU9hPz9m9vnodsEGCapdRxsXaE4xA7lg8dZ5WsaAos2TUwPQYt EyCbS9z2Yzy1UpySwZudo6OGbQIaugOtgrcCS/cvdvlRb8K4mLe+807MPGmBOGA= =7wEX -----END PGP SIGNATURE----- -- 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/
