Re: cpuinfo, bogomips and duo core

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/02/2013 13:24, Reindl Harald wrote:


Am 12.02.2013 13:38, schrieb Gordan Bobic:
-O3 -march=corei7 -mtune=corei7 -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes -fopenmp -mfpmath=sse

That just tells me you didn't push the machine to full saturation.

Virtualization takes resources, and you cannot go faster by adding overheads. The only exception to this is where
you have hardware specifically designed for this, with a hypervisor in firmware running on proprietary resources
that a generic bare metal OS wouldn't be able to access anyway (or at least it wouldn't know what to do with it).
In such cases you have an added bonus that you can reboot the host without switching off the guests (and without
migrating them elsewhere, either). But hardware like that is very proprietary and uncommon.

that just tells that you can disable a lot of services
and overhead in a VM you would never do on bare metal
and it tells that the hypervisor can schedule IO much
more efficient as a generic kernel without less overhead

Utter nonsense. On bare metal, the Linux kernel scheduling even with full awareness of the underlying CPU cores is pretty poor. C2Q is particularly good example of this because latency and cache misses between the two sets of 2 cores causes a 20%+ drop in throughput compared to pinning heavy processes to a specific core. Systems with multiple sockets also suffer from this issue particularly badly.

Now consider that you are effectively hiding the physical CPU layout behind a hypervisor that applies it's smoke-and-mirrors and makes it even harder for the guest kernel to do something reasonably sensible - so you get another 20%+ overhead on top from the extra cache misses, extra context switching overheads.

however, it does not interest me to discuss with you
after years of expierence with virtualization and bare
metal for nearly any known type of servers with very
dfifferent and mixed load

So much experience, so little understanding...
But you are right that it is off topic for this list. I shall not retort further on this thread.

Gordan
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux