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>