From owner-freebsd-emulation Wed Dec 13 13:36:56 2000 From owner-freebsd-emulation@FreeBSD.ORG Wed Dec 13 13:36:48 2000 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from guardian.sftw.com (guardian.sftw.com [209.157.37.25]) by hub.freebsd.org (Postfix) with ESMTP id 1D86A37B698 for ; Wed, 13 Dec 2000 13:36:40 -0800 (PST) Received: from vmware (vmware.sftw.com [209.157.37.197]) by guardian.sftw.com (8.11.0/8.11.0) with SMTP id eBDLaUq03315; Wed, 13 Dec 2000 13:36:30 -0800 (PST) (envelope-from nsayer@quack.kfu.com) From: "Nick Sayer" To: "Matt Dillon" , "Nick Sayer" Cc: "Barry Lustig" , , Subject: RE: RE: VMWare performance when returning from suspend to disk Date: Wed, 13 Dec 2000 13:36:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200012132111.eBDLB7g86670@earth.backplane.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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