On Wed, 3 Mar 2021, yunqiang.su@xxxxxxxxxxxxx wrote: > > > v5->v6: > > > Rollback to V3, aka remove config option. > > > > You can't reuse v3 as it stands because it breaks R6 as we previously > > discussed. You need to tell R6 and earlier ISAs apart and set the FR bit > > accordingly. > > > > It won't break r6, as all of r6 binary is FP64, and on r6 > `frdefault' is always false, and `fr1' is always true. > It won't trigger this mode switch. > > Oh, you are right, there may be a case that to run legacy app on r6 CPU. > For this case, on r6, we need to set the CPU to FRE mode. The FRE mode causes a severe performance regression for single FP operations, so we shouldn't use it for FPXX software. As a matter of interest: do you have figures available as to how many software packages are affected in Debian? Also it has now struck me that another userland workaround should be possible, by setting LD_PRELOAD in the environment system-wide to a dummy FR=0 DSO (e.g. via /etc/environment or /etc/initscript; I reckon systemd has its own way too), which will force the right mode the normal way. All the distribution has been built for FPXX I presume, right? You can distribute a package with the dummy along with the environment entry to all the people who require it. I fail to see how it could be more problematic than getting a questionable hack included in the kernel forever and then requiring everyone to upgrade the relevant packages anyway, which you will have to supply for stable releases too. Or I guess you could just rebuild libc as FR=0 instead, or is there a Golang standard library that every Golang program uses? And then have people upgrade that package instead. It seems to me like there are still a couple of alternatives available. You might be able to come up with yet more if you continued looking for them. I consider putting any workaround into the kernel the last resort really. The problem is in the userland, so let's try hard to deal with it there. Maciej
