> On Wed, 3 Mar 2021, yunqiang.su@xxxxxxxxxxxxx wrote: > > > > The FRE mode causes a severe performance regression for single FP > > > operations, so we shouldn't use it for FPXX software. > > > > > > > If we need to run pre-R6 FPXX/FP32 app on r6 CPU, it may be the only > > choice for us. > > Nope, FPXX doesn't require FRE, and FPXX is all this change is about. > > > Any way, in this case we need lots of T&E, the problem of FRE won't be > > a big problem. > > The R6 instruction set has been designed such as to minimise traps and > emulations, so there is no point to make it worse for everyone for the sake of > a broken corner case. > > > > As a matter of interest: do you have figures available as to how > > > many software packages are affected in Debian? > > > > > > > Almost all packages built with Golang in buster. > > How many is that though? Two? Ten? A thousand? syq@m530-2:~$ cat /var/lib/apt/lists/mirrors.aliyun.com_debian_dists_sid_main_source_Sources | grep 'Build-Depends' | grep golang | wc 2039 21384 344099 > > > > 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? > > > > > > > It is not acceptable for "stable" branch of distributions. > > I'd say the chosen policy of any distribution is said distribution's problem, not > the upstream kernel's. You can have a local patch for the kernel too if you > consider a kernel solution the only one that works for you. From the > discussion so far it looks to me like the least involving solution which will > make everyone happy. > It is not only about one distribution, instead of all distribution, since this is caused by the bug of Golang distribution. > > > 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. > > > > > > > Rebuiding libc to FP32 is not acceptable, since we want to do is to > > support MSA, Which require FR=1 and all the result is FP64. > > Do you have any software build for MSA with your distribution already, or do > you just plan it? How is it expected work with non-MSA hardware, which I > believe is still predominant? > I am just plan it for Debian. While currently there do be some downstream user of mipsel/Debian are using MSA on it. > Also I'll repeat myself: is there a Golang standard library that every Golang > program uses? > Yes. It even effect /usr/bin/go itself, and all of binaries its generate may be effected. > > In fact we found this problem when we try to enable > > MIPS_O32_FP64_SUPPORT, Without this option is enabled, all FPXX binaries > are still use FR=0 mode: > > See: function mips_set_personality_fp() > > > > So, here, we doesn't introduce the rollback to FR=0. > > So keep MIPS_O32_FP64_SUPPORT disabled then until the environment has > been fixed? > That is really a solution, while we still need a solution to compatible with the pre-exists binaries. > > > 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. > > > > > > > Yes. It is problem of userland, while it has no way to fix in for the > > pre-exist binaries in userland. > > I gave you examples. It appears the problem instead is with the > distribution's policy, and the kernel is not there to work it around, sorry. > It effects all distributions not only one. I am not want to change the default behavior of upstream kernel, that's why I prefer to introduce a new config option. > Maciej
