> On Sep 26, 2018, at 4:12 AM, Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > On 2018-09-20 21:15:35 [-0700], Andy Lutomirski wrote: >>> I mean the fpu.initialized variable entirely. AFAIK, its only use is for kernel threads — setting it to false lets us switch to a kernel thread and back without saving and restoring. But TIF_LOAD_FPU should be able to replace it: when we have FPU regs loaded and we switch to *any* thread, kernel or otherwise, we can set TIF_LOAD_FPU and leave the old regs loaded. So we don’t need the special case for kernel threads. >>> >>> Which reminds me: if you haven’t already done so, can you add a helper to sanity check the current context? It should check that the combination of owner_ctx, last_cpu, and TIF_LOAD_FPU is sane. For example, if owner_ctx or last_cpu is says the cpu regs are invalid for current but TIF_LOAD_FPU is clear, it should warn. I think that at least switch_fpu_finish should call it. Arguably switch_fpu_prepare should too, at the beginning. >> >> Looking some more, the “preload” variable needs to go away or be renamed. It hasn’t had anything to do with preloading for some time. > okay. > >> Also, the interaction between TIF_LOAD_FPU and FPU emulation needs to be documented somewhere. Probably FPU-less systems should never have TIF_LOAD_FPU set. > Yes, they should not. > >> Or we could decide that no one uses FPU emulation any more. > > Oh. Removing unused code? I'm all yours. > There is this Intel Quark thingy which comes to mind can still be > bought. Its data sheet[0] has this: > | 13.1 Features: > | Note: The processor does not provide an x87 Floating Point Unit (FPU) and does > | not support x87 FPU instructions > > so not only it does not support the lock prefix, no, it also relies on > soft-FPU. > The latest bsp release notes quotes a package named > quark_linux_v3.14+v1.2.1.1.tar.gz > > so they still use v3.14 (which is not a supported kernel anymore). > And then I took a look into their Yocto-BSP and found this: > | $ fgrep -R MATH_EMULATION . > | ./meta-intel-quark/recipes-kernel/linux/files/quark_3.14.cfg:# CONFIG_MATH_EMULATION is not set > > so they don't set this option. This is small SoC and does not run on any > Distro due to the missing lock prefix. So if they use yocto to recompile > everything, they can rebuild their toolchain with soft-fpu support which > is more efficient than calling into the kernel for every opcode. > > So I *think* nobody relies on FPU-emulation anymore. I would suggest to > get this patch set into shape and then getting rid of > CONFIG_MATH_EMULATION? I don’t think you can boot a kernel without math emulation on a no-FPU CPU. So maybe we should table this particular idea. I didn’t realize there were Quark CPUs without FPU.
