Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbatt!cbosgd!ncr-sd!greg
From: greg@ncr-sd.UUCP
Newsgroups: comp.arch
Subject: Re: Software Page Table Machines
Message-ID: <1562@ncr-sd.SanDiego.NCR.COM>
Date: Sat, 16-May-87 19:45:29 EDT
Article-I.D.: ncr-sd.1562
Posted: Sat May 16 19:45:29 1987
Date-Received: Sun, 17-May-87 04:39:45 EDT
References: <1968@husc6.UUCP> <668@stride.Stride.COM>
Reply-To: greg@ncr-sd.UUCP (Greg Noel)
Organization: NCR Corporation, Rancho Bernardo
Lines: 22

In article <668@stride.Stride.COM> mitch@stride1.Stride.COM (Thomas P. Mitchell) writes:
>The above line started me wondering if any system has
>considerations for per process disk optimizations.  ....
>... the person building the code might know the best
>way to do buffering or read ahead.

I modified a V6 system once to handle user-specified read-ahead.  It added
a set of seek specifiers parallel to the standard set that had the side-
effect that they started a read-ahead cycle.  That is,
    seek(file, location, 8);
was identical to
    seek(file, location, 0);
except that it also started to read the block specified in the location.  It
did help, but its effectivness was sporatic -- the disk was too slow (an RK05)
or the processor was too fast (PDP-11/40) and the common case was that there
wasn't enough processing to do after deciding which record was needed next, so
you ended up waiting anyway.  On the other hand, we did have one application
that about trebbled its performance -- it wanted to read records in clusters,
so it often would ask for eight or ten records to be pre-read, thus taking
advantage of the better seek scheduling.
-- 
-- Greg Noel, NCR Rancho Bernardo     Greg.Noel@SanDiego.NCR.COM