Adam Thornton wrote:
That said, if you have more than one actual processor, I would define all the guests as two-processor machines. It seems to me--and this is nothing I have any data to support, so Barton is not interested--that if you're running on multiple physical engines, two-processor Linux images generally make better use of the real resources than uniprocessor virtual images, and you get more consistent (less peaky) use of the real CPU resources. I *would* like to see some actual measurement data if anyone has some they can share.
It takes more than just two virtual CPUs to tango... those virtual CPUs need to be dispatched on real CPUs. That depends on the competition on VM level. Assume the total number of virtual CPUs in queue being much bigger than the number of real CPUs. If you are the only Linux with two virtual CPUs, then I can believe that chances increase that one of your virtual CPUs is being dispatched (we're not sure it's the one you liked best). But if everyone is getting two virtual CPUs it does not help you a lot. Instead, it increases the overhead in Linux (and slightly adds to the overhead for z/VM as well). So doing this test with one virtual machine does not show you much.
The Linux kernels in the distributions are all SMP, and there have been times where the non-SMP kernel would not even compile. And if it compiled, it does not really take advantage of that since much of the s390 code is written SMP-safe anyway without looking at CONFIG_SMP.
We have had recommendations that tell you to give each virtual machines as many virtual CPUs as you have real CPUs. In the context I talk about here (many more virtual CPUs runnable than real CPUs) that recommendation makes no sense. I believe you define enough virtual CPUs to provide the peak CPU requirements you may have for that virtual machine (but not more than what you have in the box at all obviously). If you define less virtual CPUs the peaks will smear - your total CPU seconds used in Linux over the day will remain the same, but the response time may get worse. So adding another CPU will make your resource usage *more* peaky, or at least the peak will be higher and shorter, if that's whay you meant (provided you get a real CPU to back it).
And this is making assumptions about the workload in Linux as well. If the CPU consumption in Linux is in a single thread, then throwing more CPUs at it will not help you. If you run a single SAP batch process pegging a CPU then even a virtual machine with 4 CPUs will not go beyond using 1 engine flat out (well, you see small peaks on top because of the background processes and scheduler etc). I also understand that some applications have been written such that they favour the background process over the user threads. With such a strange application it could make sense to have another virtual CPU that will take the user thread. And then on z/VM level these both virtual CPUs will compete equally for CPU resources and effectively make the user thread make progress even when there is background work to do. Despite the poor design of the application...
Rob
---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
