Am 24.09.2015 um 00:42 schrieb Viktor Mihajlovski: > On 23.09.2015 15:32, Grzegorz Powiedziuk wrote: >> BTW, I was playing with KVM few days ago and it looks pretty awesome in >> terms of maintaining the environment and deploying new VMs but the >> performance for me was really bad. >> And I mean extremely bad. I am not sure if it was because I made the KVM >> host (sles12) run as a virtual machine in z/VM or I was doing something >> else wrong. I know that having kvm virtual machines in a 3rd level (under >> sles -> under z/VM) will impact performance but my case it was extremly bad. >> It was like running linux in hercules s390 in 2006 on old x86 desktop. >> >> The installation of linux in kvm virtual machine took 3-4 hours. Every >> operation that involves cpu and memory takes 3-10 time more time than on a >> KVM host itself. >> Whenever something is happening in kvm virtual machine, the performance >> toolkit shows that KVM host is doing about 50% in supervisor mode and 50% in >> emulation mode which makes the t/v ratio for this machine about 2 which is >> pretty bad. I didn’t have time to do more investigation on this yet. >> The KVM host (Server) sees about 50% cpu time as a “steal time”. >> > > Although KVM should generally be run in LPAR a slowdown in an order of > magnitude in z/VM seems a bit odd. > I actually do run KVM under z/VM at my own risk (I am absolutely NOT > suggesting to do that). To recreate your problems I started a CPU burning > task in a KVM guest (stress -n 1) and see the following in the host: > > Tasks: 162 total, 1 running, 161 sleeping, 0 stopped, 0 zombie > %Cpu(s): 32,5 us, 0,7 sy, 0,0 ni, 63,8 id, 0,0 wa, 0,0 hi, 0,1 si, 2,9 > st > KiB Mem: 812852 total, 801232 used, 11620 free, 3152 buffers > KiB Swap: 7212140 total, 1789268 used, 5422872 free, 611460 cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 38763 qemu 20 0 2842280 353068 350952 S 94,8 43,4 58:46.16 > qemu-system-s39 > > As you can see it's less than 3% steal time in the host with roughly 95% > problem state CPU utilization for the guest process (which indicates that SIE > isn't too bad even for a 3rd level guest). > > The high steal time you observe could be a hint for either z/VM swapping on > behalf of the KVM host or KVM swapping itself. Could you observe a high page > rate? >
z/VM does call SIE on behalf of the guest hypervisor. So for CPU bound workload, which causes almost no SIE exits things are fine. It is the sweet spot for 2nd level. As soon as the KVM guest will have many exits (e.g. some I/O, memory fault-in, reschedule) or more than one CPU in the KVM host things can get really slow as z/VM then has to interpret lots of things. In addition z/VM 2nd level support was in no way optimized to speed up a KVM hypervisor, so I assume that some of the optimizations for z/VM under z/VM have to fall back to the slow path. Christian ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
