From owner-freebsd-emulation Wed Dec 13 13:11:16 2000 From owner-freebsd-emulation@FreeBSD.ORG Wed Dec 13 13:11:14 2000 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 13FC737B698 for ; Wed, 13 Dec 2000 13:11:14 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eBDLB7g86670; Wed, 13 Dec 2000 13:11:07 -0800 (PST) (envelope-from dillon) Date: Wed, 13 Dec 2000 13:11:07 -0800 (PST) From: Matt Dillon Message-Id: <200012132111.eBDLB7g86670@earth.backplane.com> To: "Nick Sayer" Cc: "Barry Lustig" , , Subject: Re: RE: VMWare performance when returning from suspend to disk References: Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :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