On Wed, Sep 6, 2017 at 11:59 AM, Steven Munroe
<munroesj(a)linux.vnet.ibm.com> wrote:
On Wed, 2017-09-06 at 10:31 -0400, Josh Boyer wrote:
> On Tue, Sep 5, 2017 at 10:20 PM, Steven Munroe
> <munroesj(a)linux.vnet.ibm.com> wrote:
> > On Tue, 2017-09-05 at 15:35 -0500, Carlos O'Donell wrote:
> >> On 09/05/2017 03:03 PM, Steven Munroe wrote:
> >> > On Fri, 2017-09-01 at 09:24 -0500, Carlos O'Donell wrote:
> >> >> On 09/01/2017 09:03 AM, Steven Munroe wrote:
> >> >>> If you want to cut back you can't try 970 as base, plus
power6 and
> >> >>> power7 -mtune power8
> >> >>
> >> >> s/can't/can/g?
> >> >>
> >> >> I assume you're suggestion:
> >> >>
> >> >> * 970 base multilib.
> >> >> * power6 multilib.
> >> >> * power7 multilib with power8 tunning.
> >> >>
> >> >> Which implies:
> >> >>
> >> >> * Drop the power8 multilib.
> >> >>
> >> >> That drops only 1 multilib.
> >> >>
> >> >> Do we need power6 or can we fold that into the 970?
> >> >> e.g.
> >> >>
> >> >> * 970 base multilib with power6 tuning.
> >> >> * power7 multilib with power8 tuning.
> >> >>
> >> >>
> >> >
> >> > That seems simple but is ignoring the major features added with each
ISA
> >> > level.
> >> >
> >> > So between 970 and power8 we added DFP, VSX, VSX Scalar Float, and
HTM.
> >> > This is over 300 new instructions including additions to existing ISA
> >> > categories, like Fixed Point 64-bit, Floating Point, and VMX (Altivec)
> >> > beyond what was in 970.
> >> >
> >> > So what you propose will mean Power6 would be restricted to software
> >> > emulation of DFP and the DFP hardware unused. And will not have the
> >> > mutex lock hint and compare bytes optimization.
> >> >
> >> > Power7 will get both HW DFP and VSX (vector double and extended scalar
> >> > double) but without Scalar extended Float. Also will leave the HTM and
> >> > direct moves (GPR <-> VSR) optimization disabled.
> >> >
> >> > So if you holding on to your Apple G5 you may not know what your
> >> > missing, but your P6 JS21 blade will be disappointing. And your P8
will
> >> > run slow due to missing direct move support.
> >>
> >> The library, glibc, *may* be missing the use of some of those instructions
> >> in the library and *iff* the compiler generated them as part of the
> >> compilation of generic C code.
> >>
> >> The POWER7 multilib will still have POWER8 IFUNCs which make use of
> >> all the POWER8 assembly implemented IFUNCs that IBM has contributed
> >> upstream.
> >>
> >> How much of these features you quote are actually used by glibc when
> >> compiled for that architecture?
> >>
> >> I expect user applications would make use of libdfp to access the
> >> full power of POWER6 DFP, but glibc itself doesn't use DFP internally,
> >> so I still don't see how the above suggested reduction makes things
> >> really worse.
> >>
> >> We are only talking about limiting the glibc multilibs that we build.
> >>
> >> How about:
> >>
> >> * 970 with POWER6 tuning.
> >> - Will not use DFP within glibc, but we have never used DFP in glibc.
> >>
> > Yes but customer do use DFP, Just not the customers you have talked to.
>
> How many of those customers run Fedora? That is the context of this
> conversation.
>
And you are not going to get answer to that. Because the data is not
available to me (or anyone).
And you don't have data that says they are not...
That is true, certainly. However, "customer" in the Fedora sense
doesn't make sense so we must translate that to "user" and/or
"contributor". Contributors to Fedora make the decisions taking users
into account. Considering we have very limited data on users, we have
to give more weight to what the contributors think is most supportable
going forward. The goal here is continued, sustainable support with
the limited contributor base we have.
josh