Date: Wed, 13 Dec 2000 11:52:10 -0800 From: "Nick Sayer" <nsayer@quack.kfu.com> To: "Matt Dillon" <dillon@earth.backplane.com>, "Barry Lustig" <barry@lustig.com> Cc: <vns@delta.odessa.ua>, <emulation@freebsd.org> Subject: RE: VMWare performance when returning from suspend to disk Message-ID: <IDEALNDOEODBKIHGHLGMEEAJCAAA.nsayer@quack.kfu.com> In-Reply-To: <200012130624.eBD6OKV80594@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, one thing I tried was to change the vm.pageout_algorithm to 1. That didn't help. Looking at when vmware locks, I see some VN PAGER out activity right at the start, but it doesn't last the entire length of the hang. Then when it comes BACK, one thing I see is that 94% of the CPU is in 'sys' time. In fact, the 'sys' time is sort of a barometer for vmware performance. When it dips down, vmware locks up. When it shoots back up towards 100%, vmware becomes responsive. running top in another window and watching the vmware process, I see that sure enough, it's mostly in system time. I suspect this really means that vmware does an ioctl to 'jump into' the guest os. vmware is in RUN state according to top. What I see most often from top is that vmware goes into 'inode' state when it's locked (sometimes I briefly see state vmpfw). This would suggest to me that the issue is with the mmapped RAM file. I will reboot the guest and compare what I see now to what I see with a guest that's not been suspended. btw: I am running 4.2-RELEASE. Maybe, maybe not. This sounds primarily like pagein load whereas my patches are primarily geared towards pageout load. It's possible, but not likely. A 'systat -vm 1' during the period of slowness might help. Specifically, the disk I/O, VN PAGER, and SWAP PAGER numbers. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?IDEALNDOEODBKIHGHLGMEEAJCAAA.nsayer>