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

[<yunqiang.su@cipunited.com>]

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