From owner-freebsd-current Fri Feb 9 7:28:46 2001 Delivered-To: freebsd-current@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 6DE7C37B823; Fri, 9 Feb 2001 07:15:07 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id KAA26411; Fri, 9 Feb 2001 10:14:51 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f19FELc01925; Fri, 9 Feb 2001 10:14:21 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14980.2381.849005.313177@grasshopper.cs.duke.edu> Date: Fri, 9 Feb 2001 10:14:21 -0500 (EST) To: freebsd-current@FreeBSD.ORG Cc: Dag-Erling Smorgrav , Julian Elischer , Josef Karthauser , Robert Watson , Brian Somers , Bruce Evans , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: What's changed recently with vmware/linuxemu/file I/O In-Reply-To: <14979.29437.518299.842853@grasshopper.cs.duke.edu> References: <20010208113519.A789@tao.org.uk> <3A828C2C.F7CDA809@elischer.org> <14979.29437.518299.842853@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrew Gallatin writes: > > Dag-Erling Smorgrav writes: > > Julian Elischer writes: > > > I believe that vmware mmaps a region of memory and then somehow syncs > > > it to disk. (It is certainly doing something like it here). > > > > Theory: VMWare mmaps a region of memory corresponding to the virtual > > machine's "physical" RAM, then touches every page during startup. > > Unless some form of clustering is done, this causes 16384 write > > operations for a 64 MB virtual machine... > > > > Pretty much. But the issue is that this should never hit the disk > unless we're under memory pressure because it is mapped MAP_NOSYNC > (actually the file is unlinked prior to the mmap() and a heuristic in > vm_mmap() detects this and sets MAP_NOSYNC). I take it back. At least with the latest version of vmware, it is apparently not mapped MAP_NOSYNC. I think they've moved from mmap'ing a file in $TMPDIR to just using the CONFIG.std save/resume file. Perhaps this is only if you have resumed from a suspended state... I haven't checked that out yet. At any rate, hacking linux_mmap to ad MAP_NOSYNC to mmaped files, in combination with yesterdays patch, appears to improve perf. considerably. Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message