[CentOS-devel] CentOS 7 (1503) i686 Beta Architecture

Johnny Hughes

johnny at centos.org
Sat Jun 6 09:44:29 UTC 2015


On 06/06/2015 02:43 AM, Toni Spets wrote:
> 
> 
> On Sat, Jun 6, 2015 at 12:09 AM, Johnny Hughes <johnny at centos.org
> <mailto:johnny at centos.org>> wrote:
> 
>     On 06/05/2015 03:41 PM, Trevor Hemsley wrote:
>     > Is it really worth the effort? The last Pentium III was released in 2002
>     > and you couldn't buy them after 2003 so we're talking about machines
>     > that are 12 or more years old. The fastest one you could ever buy is
>     > outperformed by a factor of more than 2 times by each core on my dual
>     > core 2010 vintage Intel Atom D510.
>     >
> 
>     I don't mind the effort of compiling so much as the potential for
>     massive confusion with 2 packages named the same thing but compiled with
>     different gcc optimizations, as we would still have to provide the other
>     packages i686 packages in x86_64 arch for multilib.
> 
> 
> Why its there a need to provide two different builds? Couldn't the
> multilib packages be rebuilt not to require SSE2? Is the performance
> penalty bad enough to not even consider it?

The reason the items in CentOS 7 x86_64 (in this case, we are taking
about the i686 multilib pacakges) need to be built with an unmodified
gcc is that the whole goal of CentOS Linux is to build packages from
RHEL sources that are as close to possible to actual Red Hat packages
minus branding.

If we change the way gcc produces those i686 packages that we put into
our main CentOS 7 x86_64 arch then that is a huge difference.  I am
quite sure our users do not want us modifying CentOS Linux 7 production
packages in this manner.

If has nothing to do with performance, it has to do with producing
CentOS Linux 7 x86_64 that deviates from the way the upstream packages
are produced.


>  
> 
> 
>     But, I do agree that trying to run this on 12 year old machines is is
>     not going to be easy.  CentOS-7 does not perform well without at least
>     1.5GB - 2GB of RAM as well.  (The installer does not even work well with
>     less than 1 GB RAM)
> 
> 
> The installer does run with 512MB of RAM and it can be run around 384MB
> of RAM as well without any modifications except lowering the requirement
> by hand. The use cases would be headless environments like servers where
> you can better utilize the memory like you do in virtualized
> environments. I do have 512MB CentOS 7 64-bit VMs that perform just fine
> for what they are tasked for.
>  
> 
> 
>     If enough people really want it, I guess it could be done as part of the
>     AltArch Special Interest Group .. but my initial take is not positive
>     because of the confusion potential.
> 
> 
>     > On 05/06/15 21:22, Toni Spets wrote:
>     >> This would be rather unfortunate as that would also leave out all
>     >> 32-bit only AMD processors (Athlon XP & co) as well according to
>     >> Wikipedia where it's said Athlon 64 was the first one to add SSE2 and
>     >> it can already run the 64-bit CentOS anyway.
>     >>
>     >> I'm hoping there is more people that could +1 having support for
>     >> pre-SSE2 CPUs so it would be seriously considered even though it might
>     >> need massive rebuild of the multilib packages. EPEL doesn't have
>     >> multilib yet (right?) so they can still adapt to whatever is going to
>     >> be done. The packages would run on upstream as well anyway.
>     >>
>     >> Taking into account the actual computing power of CPUs, I don't think
>     >> it's unreasonable to run CentOS 7 on Pentium III or Athlon XP.
>     >>
>     >> Thanks for considering.
>     >>
>     >> On Fri, Jun 5, 2015 at 9:44 PM, Johnny Hughes <johnny at centos.org <mailto:johnny at centos.org>
>     >> <mailto:johnny at centos.org <mailto:johnny at centos.org>>> wrote:
>     >>
>     >>     On 06/05/2015 05:46 AM, Vladimir Stackov wrote:
>     >>     > Greetings,
>     >>     >
>     >>     > currently we are maintaining own CentOS 7 i686 rebuild and I
>     >>     would like
>     >>     > to kindly ask you to replace following macros from gcc.spec:
>     >>     >
>     >>     > %if 0%{?rhel} >= 7
>     >>     > %ifarch %{ix86}
>     >>     >    --with-arch=x86-64 \
>     >>     > %endif
>     >>     > %ifarch x86_64
>     >>     >    --with-arch_32=x86-64 \
>     >>     > %endif
>     >>     >
>     >>     > with that:
>     >>     >
>     >>     > %if 0%{?rhel} >= 7
>     >>     > %ifarch %{ix86}
>     >>     >         --with-arch=i686 \
>     >>     > %endif
>     >>     > %ifarch x86_64
>     >>     >         --with-arch_32=i686 \
>     >>     > %endif
>     >>     >
>     >>     > x86-64 causes gcc to use extended instruction set for produced
>     >>     code and
>     >>     > it's impossible to run CentOS 7 i686 on older systems
>     without SSE2
>     >>     > instruction because of SIGILL.
>     >>     > This affects Pentium 3, old VIA CPUs, old Xeons and some
>     others.
>     >>     >
>     >>     > Is that possible?
>     >>     > Thanks!
>     >>     >
>     >>
>     >>     <snip>
>     >>
>     >>     I don't think we can do this as I also use the RPMs produced
>     for the
>     >>     multilib portion of CentOS-7 x86_64 and we want our RPMs to
>     be like
>     >>     those from upstream for that purpose.
>     >>
>     >>     Thanks,
>     >>     Johnny Hughes
>     >>
>     >>
> 
> 
> 
>     _______________________________________________
>     CentOS-devel mailing list
>     CentOS-devel at centos.org <mailto:CentOS-devel at centos.org>
>     http://lists.centos.org/mailman/listinfo/centos-devel
> 
> 
> 
> 
> -- 
> Toni Spets
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150606/8995f9c6/attachment-0004.sig>


More information about the CentOS-devel mailing list