From owner-freebsd-hackers Wed Feb 28 6:18:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id 2040437B719; Wed, 28 Feb 2001 06:18:24 -0800 (PST) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 4AC4F54F4; Wed, 28 Feb 2001 15:18:23 +0100 (CET) Date: Wed, 28 Feb 2001 15:18:23 +0100 From: Anton Berezin To: Mike Smith Cc: Peter Dufault , hackers@freebsd.org Subject: Re: how to actually find out whether data hit the disk? Message-ID: <20010228151823.D29400@heechee.tobez.org> References: <200102281357.f1SDvVW27830@hda.hda.com> <200102281407.f1SE7oi01870@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102281407.f1SE7oi01870@mass.dis.org>; from msmith@freebsd.org on Wed, Feb 28, 2001 at 06:07:50AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ putting hackers- back here] On Wed, Feb 28, 2001 at 06:07:50AM -0800, Mike Smith wrote: > > > I am doing the following, on the partition with softupdates turned on: > > > > > > 1. fd = open("a file", O_CREAT) > > > 2. mmap(fd) > > > 3. sequencial write to mmapped region > > > 4. some other processing > > > 5. munmap > > > 6. unlink > > > 7. close > > > > > > Since this is a supposedly high-perfomance application, I am interested > > > that data do NOT hit the disk. I understand that softupdates do a good > > > job at that. The time taken by step 4 is usually sub-second, but > > > sometimes it can take longer (network delays etc.). The question is - > > > is it possible to actually find out whether data hit the disk or not for > > > a particular run of 1-7? > > The *real* question here is - why are you using a file at all? > > You could trivially replace open/mmap with malloc, and munmap/unlink/ > close with free. If you don't want the operation to go to disk, don't > apply disk-file semantics to it at all. That's a sort of memory overcommit protection. The files/buffers are potentially large (say, ~20MB-100MB), there can be several of those in a process, and there are going to be several copies of a process. So neither malloc() nor anonymous mmap() do the job. In most cases they would work just fine (i.e, the typical buffer size is 2K-500K), but so will do the file-backed mmap(). In the bad case, however, the file-backed mmap() will have an advantage of not coredumping. ;-) %Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message