reiter@endor.harvard.edu (Ehud Reiter) (05/12/87)
Some friends of mine are playing around with memory-mapped databases. They are interested in finding a machine which supports 1) Software control of the virtual-to-real memory mapping. That is, when a TLB miss occurs in the MMU, they want to have their own program fill in the TLB entry, not depend on a hardwired hardware algorithm. 2) Large address space. This is less important, but since there are plenty of databases out there which are larger than 4 GB, they'd like a machine with 40 (or more) addressing bits. 3) Networking. This is supposed to be a distributed database, so good networking is a must! So if you know of any machine which fits all (or most) of the above requirements, please let me know. Note that I'm not sure if this is going to be a paper study, or if they're actually planning to build something. Thanks. Ehud Reiter reiter@harvard (ARPA,BITNET,UUCP) reiter@harvard.harvard.EDU (new ARPA)
mitch@stride1.UUCP (05/15/87)
In article <1968@husc6.UUCP> reiter@endor.UUCP (Ehud Reiter) writes: >Some friends of mine are playing around with memory-mapped databases. > The above line started me wondering if any system has considerations for per process disk optimizations. For example in a database the person building the code might know the best way to do buffering or read ahead. I know many programs are built to take advantage of known disk optimizations, but not the other way around. Perhaps something like: -=-=--= #include <disk-opt.h> -stuff- int fd; -stuff- fd = open(argv[1], O_RDWR) disk-optim(fd, {BUFFER, READ_AHEAD, READ_BEHIND}) -stuff- Thanks for the Soap Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702) 322-6868 TWX: 910-395-6073 MicroSage Computer Systems Inc. a Division of Stride Micro. Opinions expressed are probably mine.
greg@ncr-sd.UUCP (05/17/87)
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
earl@mips.UUCP (Earl Killian) (05/17/87)
In article <668@stride.Stride.COM>, mitch@stride1.UUCP (Thomas P. Mitchell)
asks about per process disk optimizations.
I don't think this is uncommon in operating systems. Systems are
often written to accept "hints" from programs.
One example: the ITS operating system (for the PDP10) has system calls
to declare that part of your virtual memory (which can be mapped to a
file or not) is going to be referenced sequentially. When you page
fault on page I it starts the disk read for I+N (or I-N) depending on
what the user specified. One use of this was in the editor (the
original EMACS); string searches used this mechanism to get the pages
to be scanned read in faster.gwu@vlsi.cs.cmu.edu (George Wu) (05/20/87)
Concerning the discussion about pre process disk optimizations:
I'm not sure whether this was a Berkeley call or something Sun did, but I
remember a long time ago in a Sun-2 manual that there was a system call which
told the system how you expected to access your data. There were three
different "modes:" the system default, some sort of number-of-accesses based
algorithm; sequential access; and completely random access.
I presume this was all to allow the system to determine what page(s) was
best to swap out. And it would all have to be per process.
George