From owner-freebsd-hackers  Fri May 16 12:17:09 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id MAA14291
          for hackers-outgoing; Fri, 16 May 1997 12:17:09 -0700 (PDT)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA14274;
          Fri, 16 May 1997 12:17:02 -0700 (PDT)
Received: (from root@localhost) by dyson.iquest.net (8.8.5/8.6.9) id OAA00300; Fri, 16 May 1997 14:16:05 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199705161916.OAA00300@dyson.iquest.net>
Subject: Re: mmap()
In-Reply-To: <199705161744.KAA17629@phaeton.artisoft.com> from Terry Lambert at "May 16, 97 10:44:41 am"
To: terry@lambert.org (Terry Lambert)
Date: Fri, 16 May 1997 14:16:05 -0500 (EST)
Cc: dyson@FreeBSD.ORG, james@westongold.com, freebsd-hackers@FreeBSD.ORG
Reply-To: dyson@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > Okay!!!  Firstly, the FFS FS dependent VOP_GETPAGES does do read-aheads iff
> > the object is marked with MADV_SEQUENTIAL.  Secondly, it would be fairly
> > easy to detect sequential behavior automatically.  Right now, there are
> > much bigger fish to fry!!!  :-) (The reason that it is in the FS dependent
> > code, is that it is only optional that one uses the cluster read ahead
> > code on a per filesystem basis.)  It is likely that the FFS dependent
> > VOP_GETPAGES code will work with other filesystem types (perhaps with
> > minor mods.)
> 
> It seems to me that the OBJ_SEQUENTIAL blocks the VOP_GETPAGE() caller
> until all pages have been faulted, instead of asynchronously doing the
> pages following the requested page, and returing immediately for the
> requested page.  This would introduce "bursty" behaviour, as sequential
> access would incur a large latence for every read-ahead trigger.
> 
> It seems to me that this is not what he is asking for?
> 
> Else how do you explain the factor of 2 performance degradation he is
> seeing when using mmap() I/O over standard file I/O (with associated
> copies)?
> 
I don't know, I just tried this program, while copying a 12MB file
to/from the same partition on a Seagate Hawk drive, and it
took 6 seconds realtime.  Doesn't seem too awful bad to me...
Esp since the standard "cp" command takes 14 seconds realtime.

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>


#ifndef MAP_FILE
#define MAP_FILE 0
#endif


int
main (argc, argv)
int argc;
char **argv;
{
    int fdin, fdout;
    char *src, *dst;
    struct stat statbuf;

    if ((fdin = open (argv[1], O_RDONLY)) < 0)
    {
	perror ("open source file failed");
	exit (1);
    }
    if ((fdout = open (argv[2], O_RDWR | O_CREAT | O_TRUNC, 0644)) < 0)
    {
	perror ("open destination file failed");
	exit (1);
    }

    (void) fstat (fdin, &statbuf);
    (void) lseek (fdout, statbuf.st_size-1, SEEK_SET);
    (void) write (fdout, "", 1);

    src = (char *) mmap (0, statbuf.st_size, PROT_READ, MAP_FILE | MAP_PRIVATE, fdin, 0);
    if (src == (caddr_t) -1)
    {
	perror ("mmap source file failed");
	exit (1);
    }

    dst = (char *) mmap (0, statbuf.st_size, PROT_READ | PROT_WRITE, 
                                    MAP_FILE | MAP_SHARED, fdout, 0);
    if (dst == (caddr_t) -1)
    {
	perror ("mmap destination file failed");
	exit (1);
    }
    (void) memcpy (dst, src, statbuf.st_size);
    return (0);
}