cpuinfo, bogomips and duo core

[Reindl Harald]

Am 12.02.2013 18:33, schrieb Tom Horsley:
> On Tue, 12 Feb 2013 17:37:06 +0100
> Reindl Harald wrote:
> 
>> you can not do this because you can hardly deploy packages
>> built this way on a i7-3770 (Ivy Bdrige) to a Xeon E5640
>> which is Westmere architecture without ending in "unknown
>> CPU instruction" and random crashes and in the worst case
>> this will hit you due vMotion if the host where you started
>> a guest has the newer instructions and the target machine
>> not - if this happen due failover you are done at all
> 
> Ahh, but that sort of thing is what the GNU "indirect
> function" relocation code is all about. You can build
> libraries which decide at runtime which version of a
> routine to call and include multiple architecture variants
> of routines.
> 
> That makes it possible to have dozens of different versions
> of routines, only one of which has a bug so it only fails
> on certain architectures. Such a helpful feature :-)

besides you missed the "why not use -mnative" this would
blow up your binaries - in case of having 30 virtual machines
and 7 workstations with which makes 9 hosts and none of them
is older than 2 years you want to optimize in speed and size
by prefer speed but not for all prices

and i doubt that the feauture will not 100% work with any
generic software like mysql, httpd, dovecot, dbmail, openssl
which are a subset of my self-compiled RPM packages

in case of PRODUCTION you should prefer a good compromise
between performance, maintaince work and stability and
avoid risk the latter

additionally in case of vMotion/Failover you also need
EVC* and so the more optimized code would not be used
on the SandyBdridge Host as long you have a Westmere
CPU in the cluster, but it may happen that you build
RPMs on a physical machine with IvyBrdige in a testing
environment before a dist-upgrade with the target to
roll them out on the cluster later - here you would not
have EVC

*
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005764



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20130212/9c265af4/attachment-0001.sig>