Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxxxx> writes: > Matthew Fortune - 2015-01-08 12:01:50 > > > > + /* Avoid inadvertently triggering emulation */ > > > + if ((value & PR_FP_MODE_FR) && cpu_has_fpu && > > > + !(current_cpu_data.fpu_id & MIPS_FPIR_F64)) > > > + return -EOPNOTSUPP; > > > + if ((value & PR_FP_MODE_FRE) && !cpu_has_fre) > > > + return -EOPNOTSUPP; > > > > This is perhaps not important immediately but these two cases can > > be seen as inconsistent. I.e. FR1 is emulated if there is no FPU > > but FRE is not emulated if there is no FPU. > > > > I believe this would be more consistent: > > > > if ((value & PR_FP_MODE_FRE) && cpu_has_fpu && > > !cpu_has_fre) > > return -EOPNOTSUPP; > > > > The kernel then freely emulates any requested mode when there is > > no FPU but sticks to only true hardware modes when there is an FPU. > > > > = More detailed discussion = > > > > There has been debate internally at IMG over the issue of FPU emulation > > so I think it is appropriate to comment on why emulation is not always > > desirable according to the new o32 FP ABI extensions. I'll try to be > > brief... > > > > The simple reason is that it is obviously better to use a true hardware > > FPU mode whenever possible. > > I would like to point you to fact that the best choice to use the hardware > efficiently is to know which kind of hardware you have. >From that perspective the PR_SET_FP_MODE does just that except user-mode discovers the modes by simply trying to use them in order of most desirable to least desirable. I don't deny that the user code may benefit from knowing upfront what is available and being able to select an emulated mode if it *actively* chooses to do so. > So, it would be much better if application (read - GLIBC/bionic library) > gets the HW description available in HWCAP and make a choice during library load > instead of guessing via syscalls in attempt to use one or another FPU/SIMD mode. > Guessing may easily get a non-optimal HW configuration. Guessing cannot get a non-optimal mode if the PR_SET_FP_MODE only succeeds for true hardware modes. What can happen is that the user could fail to find a mode that it needs even though the kernel could have emulated it. I agree that it may be a useful to offer the user the opportunity to select an emulated mode though. > And kernel can just support an application choice via using a real HW or emulation if > application do some choice because there is no variants (example: FPU absence). Would your concerns be addressed by adding another bit to the new PR_SET_FP_MODE option that says the user is willing to accept an emulated mode: #define PR_FP_MODE_EMU (1<<2) I do not propose that this is returned from PR_GET_FP_MODE to indicate if emulation is in use or not though. PR_GET_FP_MODE should just return the mode in use regardless of emulation. In addition to this extra control bit the updated behaviour of allowing a PR_SET_FP_MODE without PR_FP_MODE_EMU should succeed if the current mode matches the requested mode. This gives the user the ability to choose a mode falling back to emulation if they desire. Please bear in mind that this prctl call is for use solely in dynamic linkers and other similar very low level system code. It is not a general end user feature. To find the best mode PR_SET_FP_MODE should then be used as follows with the use of emulated modes carefully controlled to avoid unnecessary use. 1) dynamic linker needs FR0 mode: Try PR_FP_MODE_FR0 Try PR_FP_MODE_FR1|PR_FP_MODE_FRE Try PR_FP_MODE_EMU|PR_FP_MODE_FR0 Try PR_FP_MODE_EMU|PR_FP_MODE_FR1|PR_FP_MODE_FRE 2) dynamic linker needs FR1 mode: Try PR_FP_MODE_FR1 Try PR_FP_MODE_EMU|PR_FP_MODE_FR1 3) dynamic linker needs FRE mode: Try PR_FP_MODE_FRE Try PR_FP_MODE_EMU|PR_FP_MODE_FRE This is fully compatible with the dynamic linker implementation which is already committed to glibc but allows the implementation to be extended in further work to also enable the use of emulated modes. You can go as far as to have a request to use an emulated mode actually disable an FPU even if the hardware version of the mode is available! I do not see any need for HWCAPs for these features as it is such a niche area. These are fundamental ABI support details that should be hidden as deeply as possible from an ordinary user. Thanks, Matthew
