Date: Wed, 13 Dec 2000 13:11:07 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: "Nick Sayer" <nsayer@quack.kfu.com> Cc: "Barry Lustig" <barry@lustig.com>, <vns@delta.odessa.ua>, <emulation@freebsd.org> Subject: Re: RE: VMWare performance when returning from suspend to disk Message-ID: <200012132111.eBDLB7g86670@earth.backplane.com> References: <IDEALNDOEODBKIHGHLGMEEAJCAAA.nsayer@quack.kfu.com>
next in thread | previous in thread | raw e-mail | index | archive | 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
Ok, that has nothing to do with my pageout stuff, then.
I've no idea what is going on here, but it might be useful to break into
DDB (ctl-alt-esc on the console) while the sys time is locked up then
do a 'trace' to see where the kernel is looping. 'cont' to continue.
Repeat a couple of times and you should have a good idea as to the cause
of all the sys time wasteage.
: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.
Could be.
-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?200012132111.eBDLB7g86670>