Hi Victor, I would say, tell your Open group to NOT look at the Linux point of view. Linux is wrong, or perhaps I should say any virtualized guest is wrong. A guest can only report on its own metrics and doesn't know what happens outside its own machine. Only the host has the correct view.
IIRC Barton Robinson once commented that Linux used to use the wall-clock time to calculate the CPU usage. So it was quite easy to compensate the Linux view with z/VM metrics. When virtualization became more common the kernel started reporting on steal time. But the reported CPU and steal time is more or less a guess of what is going on. Sometimes the kernel guesses correctly, most of the time it doesn't. Example: We used to have a couple of Linux guests with a HARDLIMIT at 10%. Each night during batch our Linux group would get a ticket because the machine was at 100% CPU for 2.5 hours. The customer wanted the 10% limit based on their allowed batch window and the license costs they would have with higher capacity. Second example: An LPAR had poor performance in its Linux guests. The customer wanted to add an IFL as they saw poor numbers in the SAR reporting (High CPU, High Steal). In z/VM we noticed quite a lot of CPU wait. We have solved that by reconfiguring the SHARE settings for all guests in this z/VM. Another example: When a VSE competes for CPU resources it just reports 100%, regardless of its actual CPU usage. Our z/VM is capped at 7 MIPS. So when the VSE is running any kind of load it reports 100% CPU. Similarly we used to run batch in an environment with 2 LPARs, 8 VSEs and 3 shared processors. Each VSE reported anywhere between 10 and 100% CPU depending on the jobs running in other LPARs and other VSE guests. As for the issue at hand. Is there actually a problem in performance, like Online too slow or batch window too short? Is the High CPU usage an actual problem? Is a high steal rate a problem? It also depends on the purpose of the guest. A production machine might require more CPU, but when it's consumed by a test or development machine then you might want to lower SHARE settings for guest with a lower priority. When one machine is running batch or a high CPU application, that might give higher CPU and steal rates in other guests as well. If there is indeed a problem, then first take a look at CPU_Wait for the guests. If z/VM reports a high CPU_Wait for a guest then you might want to increase SHARE for that guest. But keep in mind that you need to review the entire VM system, not just one single guest. That's what I did in the case of the second example, I listed the CPU usage and CPU_Wait for all machines for a couple of days. And then determined what the best SHARE would be for each guest. Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van Sleeuwen Flight Forum 3000 5657 EW Eindhoven -----Original Message----- From: Linux on 390 Port <LINUX-390@VM.MARIST.EDU> On Behalf Of Victor Echavarry Sent: Thursday, 21 January 2021 14:57 To: LINUX-390@VM.MARIST.EDU Subject: Best stealing explanation for z/Linux under z/VM Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. Does anybody know a explanation and/or presentation that explain the z/Linux steal under z/VM? The open group uses the argue that shows steal under the guest is one of the reason of high CPU usage. But when I check under velocity the VM is fine and shows no contention of any guest or show the high steal and idle. Regards, Victor Echavarry System Programmer Operating Systems EVERTEC, LLC WARNING: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of EVERTEC, Inc. or its affiliates. Finally, the integrity and security of this message cannot be guaranteed on the Internet, and as such EVERTEC, Inc. and its affiliates accept no liability for any damage caused by any virus transmitted by this email. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=04%7C01%7CBerry.vanSleeuwen%40atos.net%7Ccf2a6ad75ab343d1fd9808d8be2a9f22%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637468437556806727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OvGrROF0uRoz14EZApuV5IOrN8oWeyAZO0mkuFaTlLk%3D&reserved=0 This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, Atos’ liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. On all offers and agreements under which Atos Nederland B.V. supplies goods and/or services of whatever nature, the Terms of Delivery from Atos Nederland B.V. exclusively apply. The Terms of Delivery shall be promptly submitted to you on your request. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
