I remember that back when a place I worked was running MVS/ESA guests we found that there was a point in their IPL processing that required a second processor to produce startup diagnostics it the IPL failed; without the second processor the guest would just hang. We added a second vCPU to get around this. Maybe the problem is fixed in z/OS?
J. Leslie Turriff VM Systems Programmer University of Central Missouri Room 400 Ward Edwards Building Warrensburg MO 64093 660-543-4285 660-580-0523 [EMAIL PROTECTED] >>>Rob van der Heij <[EMAIL PROTECTED]> 01/10/07 4:00 am >>> On 1/9/07, David Boyes <[EMAIL PROTECTED]> wrote: >The simulation in VM allows 1 physical CPU to service multiple virtual >CPUs. It's not optimum, but it can still make a difference in the >operation of the Linux application. Notes is my favorite example of >this. On a uni, Notes does some tasks sequentially and blocks other >things while those tasks are in progress. On a virtual MP, those >long-running tasks get scheduled on one of the other processors, and you >get better application behavior. Notes is also my favorite example, but not of many good things... ;-) I have also heard this story, but nobody showed me data to prove it... The idea is that the application decides to run a different part of the workload than what you believe is important to run at that time. By means of this trick you fool Linux in thinking it can do two tasks at the same time, and under the covers have VM share processing resources among those two tasks. In a constrained system, this will make your important task run at half the speed it could: better than nothing. But what if the application *does* want to run what you believe is important to run. If you fool Linux to think there's two CPU's, it will also run less important work in parallel... You get VM to allocate resources to both workloads, and in a constrained system this means your important work runs at half the speed... So the scheme would only help if the application most of the time does the wrong thing. Notes is my favorite example... ;-) For clarity of the argument, I think we should refer to this as a bug or design fault. Giving the server more virtual CPU's than it needs (to burn the average number of cycles) may be a bypass for that bug. Depending on how constrained your system is (not just the number of CPU's) it may or may not hurt to use this trick for applications without that bug. And indeed, if you have excess capacity for the workload many tuning knobs have no effect. YMMV Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
