Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!egisin
From: egisin@watmath.UUCP
Newsgroups: comp.os.minix
Subject: Re: Disk Scheduling (& note to Dr T.)
Message-ID: <5841@watmath.UUCP>
Date: Tue, 10-Mar-87 17:46:04 EST
Article-I.D.: watmath.5841
Posted: Tue Mar 10 17:46:04 1987
Date-Received: Wed, 11-Mar-87 00:58:09 EST
References: <236@inuxf.UUCP>
Sender: egisin@watmath.UUCP
Distribution: net
Lines: 43

In article <236@inuxf.UUCP>, matt@inuxf.UUCP (Matt Verner) writes:
> 
> I am planning on adding true disk scheduling to MINIX as part of an over-all
> study of operating system efficiencies.  The existing method in MINIX is a 
> First-come-first-served pipeline with no disk i/o queue.  I would like to
> through out a straw man proposal for a method so that the alert among you
> folks can poke holes, make suggestions, etc.

A disk IO queue would improve performance only if the FS task
were modified to do asynchronous IO to the device tasks.

As-is, FS only does synchronous IO by using sendrec in fs/device:rw_dev().
Every system call that goes thru the FS task is completed
before another system call is accepted, with the exception of blocking
reads from a tty or a pipe. These are handled with lots of special-case code.

One of the effect of this is only one disk IO operation is pending
at a time, and only one disk device is active at a time.
If you have a floppy and a hard disk being accessed by two independent
processes, only one device will be active at a time (the floppy will
slow down the hard disk considerably).

What you would like to do when FS blocks for device IO
is to suspend the current system call in FS and the calling process;
accept another system call and start processing it.
This would allow multiple IO requests to be queued to the device tasks.
This is possible in Unix and probably Tunis (a monitor-based Unix-like OS)
because file system calls are procedure based, and each process
in the file system has it's own context (stack) that can be suspended
and resumed. Message passing systems make things difficult.
There is no way to suspend FS while waiting for the device to finish IO
with out a ugly rewrite of FS.  For example a write()
could do a number of device reads of indirect blocks,
then reads of partial blocks written, then writes of modified blocks.
You would have to be able to suspend and restart an FS operation
at any of these device IO operations, which could only be done
with a messy state driven FS task.

However, there are a couple of places in FS you could easily do asynchronous
IO.  One is do_sync, the other is read_ahead().  I don't know how much
this would improve performance when coupled with queues in the device tasks.

	Eric Gisin, egisin@math.waterloo.edu, watmath!egisin.