>> - virtual machines impose a penalty of 1% or more -- worse when >> not optimally configured
That's not even the half of it. I've done a few deep dives in VM performance and one of the more insidious problems is scheduling multiple CPUs for a VM. I was having a discussion with another engineer about HUGE systems with a hundred or so CPUs and the problem is that you can't get even close to the performance with a VM. When a VM is scheduled, each CPU that is used in the VM has to be scheduled at the same time so it appears to be a system. In a multi-threaded process each thread can be scheduled when it is free. In a VM, all the CPUs have to be in lock-step. If you have 32, 64, or however many CPUs, you will never come close to the performance of raw processes with a VM. This is why containers are such a win. Each thread in a process in a container is scheduled as any other thread. Don't get me wrong, VMs have a very important place and we use them all the time. It's just that they aren't as efficient. >> >> - the mitigations for various speculative execution and memory >> hammer attacks can impose 2-30% penalties depending on >> specific programs >> >> - changes between stable kernel versions can be +/- 15% in some >> cases I think that Intel's hyper-thread crap is a terrible design and many of their chips can not be made safe. So many exploits, like Row hammer, are a direct result of this bad design. In IBM's servers, at least a few years ago, made a decision to disable hyper-threading all together because the heat from the hyper-thread processing had the CPU throttling the clock and was causing a net loss in processing. Without getting into too much detail, their SVC server product had a real-time polling process that maintained timers on various processes, if the processing took too long, the system would "fail-over" to the other node. They were getting too many timeouts with hyper-threads enabled. _______________________________________________ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
