On Tue, Jan 13, 2015 at 10:13 AM, Rik van Riel <[email protected]> wrote: > -----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. >
Is the idea that it's possible for fpu_owner == fpu if the task is brand new (i.e. fpu_owner really refers to some now-dead task whose memory is reused) but that, if this is the case, then last_cpu won't match that cpu? If so, then I think that I'm finally starting to understand that part of it. >>> 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. Phew. Thanks, Andy > > > - -- > 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----- -- Andy Lutomirski AMA Capital Management, LLC -- 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/
