On 2016-03-16 11:58, Richard W.M. Jones wrote: > On Tue, Mar 15, 2016 at 10:49:14PM +0000, Gordan Bobic wrote: >> On 2016-03-15 22:12, Richard W.M. Jones wrote: >> >On Tue, Mar 15, 2016 at 07:49:22PM +0000, Gordan Bobic wrote: >> >>On 2016-03-15 18:32, Richard W.M. Jones wrote: >> >>>I may be missing some context here, but is there some reason not to >> >>>just use a VM? >> >> >> >>Performance for one. >> > >> >Can you precisely quantify that? >> >> On ARM? No, haven't tried it yet. On x86-64? Between 30% and 40% >> on a concurrent load saturating the CPU. Measured with different >> hypervisors (KVM, Xen and ESXi) and different generations of >> Intel CPUs from Core2 to Westmere Xeons. The results are reproducible >> on different loads, from a simple parallel kernel compile to a >> parallel read-only replay of MySQL general log. > > You must be doing something very wrong if you see such a huge slowdown > with KVM. Red Hat has a team that tracks performance and looks for > regressions between releases. You shouldn't see more than a 5% > slowdown, except in rare and exceptional corner cases, or if it's > configured wrong. Did you try the test as I mentioned and measure and observe the results for yourself? It would be more productive to compare empirically measured numbers with empirically masured numbers rather than empirically measured numbers with marketing brochure contents. And/or saying that the user is "holding it wrong". > Hard to say what - perhaps not using virtio, Virtio shouldn't be a factor when the entire process is running in RAM on tmpfs and never touches disk or network I/O. > or not > using the right <cpu> model, or maybe overprovisioning. I never over-provision. The VM has exactly the number of cores the host has, and the host ran no other CPU consuming tasks in any of the tests, other than the hypervisor. >> Here are some old results on Core2 class hardware: >> https://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/ > > I can't comment on VMware, nor on results from 4 years ago. As I mentioned, the results are very repeatable on much more recent hardware and software stacks. Happy to re-run it again on EL7 on my dual socket Westmere this wekend and share the results, but I don't expect things to have changed significantly. >> Unfortunately, later version of both hypervisors and hardware >> (I last ran similar tests using MySQL last year), exhibit the >> exact same performance degradation. >> >> To reproduce: >> 1) 1 host, 1 VM >> 2) Give the VM all CPU cores available on the host >> 3) Run test with double the number of threads as there are CPU cores > > So the problem is overprovisioning. If you under-provision then you are reducing the number of CPU cores available to the VM compared to what it would have on bare metal. This counts as overhead however you spin it (and it doesn't actually change the overall results for the better). And nV=nP isn't overprovisioning (or underprovisioning). This is one of the reasons why some very large installations run on a "bare metal cloud" concept (they spin up physical machines rather than virtual ones). >> >I think RHELSA 7.3 will have a 4.5 kernel. Of course "LT" kernels >> >aren't really relevant for Red Hat, because we spend huge amounts of >> >money supporting our kernels long term. >> >> Let's not go there: >> https://bugzilla.redhat.com/show_bug.cgi?id=773107 > > We don't support self-compiled kernels, for fairly obvious reasons. The problem here is that it also extends to ignoring patches that fix what are pretty obvious mis-patch bugs that by pure luck alone don't trigger failures on the specific configuration used. You'd think that at least "make allyesconfig", "make allmodconfig" and "make allnoconfig" would be tested to pass after heavily patching the kernel. In the case of that particular bug, IIRC, "make allnoconfig" would have picked up the FTBFS. When one provides a patch that fixes the problem, it is difficult to not be left disappointed about the care about the quality of the code when it gets brushed aside like that. It's one of the reasons I stopped bothering filing distro level bug reports and have switched to running mainline kernels on many of my deployments. Gordan