Re: 回复: [PATCH v6] MIPS: force use FR=0 for FPXX binary

From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: yunqiang.su@cipunited.com
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	jiaxun.yang@flygoat.com, linux-mips@vger.kernel.org
Subject: Re: 回复: [PATCH v6] MIPS: force use FR=0 for FPXX binary
Date: Wed, 3 Mar 2021 03:56:13 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.21.2103030321240.19637@angie.orcam.me.uk> (raw)
In-Reply-To: <000701d70fd0$ecbb21a0$c63164e0$@cipunited.com>

On Wed, 3 Mar 2021, yunqiang.su@cipunited.com 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