Date: Wed, 28 Feb 2001 15:18:23 +0100 From: Anton Berezin <tobez@tobez.org> To: Mike Smith <msmith@freebsd.org> Cc: Peter Dufault <dufault@hda.hda.com>, hackers@freebsd.org Subject: Re: how to actually find out whether data hit the disk? Message-ID: <20010228151823.D29400@heechee.tobez.org> In-Reply-To: <200102281407.f1SE7oi01870@mass.dis.org>; from msmith@freebsd.org on Wed, Feb 28, 2001 at 06:07:50AM -0800 References: <200102281357.f1SDvVW27830@hda.hda.com> <200102281407.f1SE7oi01870@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010228151823.D29400>