From owner-freebsd-emulation Wed Dec 13 11:52:30 2000 From owner-freebsd-emulation@FreeBSD.ORG Wed Dec 13 11:52:28 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 47C2237B400 for ; Wed, 13 Dec 2000 11:52:28 -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 eBDJqAq01303; Wed, 13 Dec 2000 11:52:10 -0800 (PST) (envelope-from nsayer@quack.kfu.com) From: "Nick Sayer" To: "Matt Dillon" , "Barry Lustig" Cc: , Subject: RE: VMWare performance when returning from suspend to disk Date: Wed, 13 Dec 2000 11:52:10 -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: <200012130624.eBD6OKV80594@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 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