Date: Wed, 13 Dec 2000 13:36:29 -0800 From: "Nick Sayer" <nsayer@quack.kfu.com> To: "Matt Dillon" <dillon@earth.backplane.com>, "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: <IDEALNDOEODBKIHGHLGMMEAJCAAA.nsayer@quack.kfu.com> In-Reply-To: <200012132111.eBDLB7g86670@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Oh what a difference power cycling the guest makes!
Now when the guest idles, the sys time is very low. When the guest is
active, the sys time creeps up. The system is fully responsive and there are
no periods when either system seem to lock up and thrash about on the disk.
Naturally, of course, as soon as I am done typing that paragraph, the sys
time shoots up to the roof. :-)
Everything remains functional -- no strange hangs. I guess under some
circumstances vmware is capable of telling when the guest CPU is idle and
sometimes it isn't. But in any case, the systat -vm 1 display now no longer
looks terribly different than it does after a suspend/resume cycle (but I
guarantee that the periodic short hangs will return).
One thing that appears different is that the number of active pages seems
much higher than when things are bad. Let me suspend/resume and see if that
holds up.
Well, immediately across the suspend/resume, the number of active pages has
been cut in half. The number of wired pages is down by 10,000 (out of about
50,000). The number of free pages is up dramatically, and every once in a
while it will freeze up, have a short burst of VN PAGER out activity, then
come back. Also, the number of inactive pages is up dramatically as well.
good bad
wired 84580 48108
act 88708 60924
inact 9456 56324
cache 6792 7304
free 572 17448
I know it may look like 'good' and 'bad' are interchanged, but they're not.
The numbers in the 'bad' column represent what systat looks like when the
periodic freezing is taking place (after a suspend/resume), 'good' is when
you boot up the guest cleanly.
-----Original Message-----
From: Matt Dillon [mailto:dillon@earth.backplane.com]
Sent: Wednesday, December 13, 2000 1:11 PM
To: Nick Sayer
Cc: Barry Lustig; vns@delta.odessa.ua; emulation@freebsd.org
Subject: Re: RE: VMWare performance when returning from suspend to disk
:
: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.
No no. vmware is _working_ when the sys time is high. When the sys time dips
low, vmware locks up. I know it makes no sense.
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?IDEALNDOEODBKIHGHLGMMEAJCAAA.nsayer>