Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!uunet!mcsun!hp4nl!star.cs.vu.nl!ast@cs.vu.nl
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Recap on past 2 weeks
Message-ID: <7217@star.cs.vu.nl>
Date: 2 Aug 90 10:36:28 GMT
Sender: news@cs.vu.nl
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Lines: 50


I'm back and beginning to dig out from the usual immense pile of email,
news, snail mail, and most recently FAXes.  If Andy Warhol's ghost ever
offers you the chance to be famous for 15 minutes, try to bargain for less
time.

I don't plan on commenting on everything in detail, but two topics seemed
to dominate the news group: FS and money.

First, FS.  There is no way I am ever going to muck up FS just to adding
multithreading.  As far as I can see, all this would do is improve performance
in a limited number of circumstances.  MINIX is intended for personal
computers.  These usually have 1 user and 1 active process.  Under these
circumstances, there is no gain whatsoever from multithreading FS since there
is nobody else who wants to use it when the one process is blocked.

If you have a foreground and a background job, and one of them is CPU bould
while the other is I/O bound, there is similarly no gain.  The only gain
comes when there are two or more I/O bound jobs, statistically not common,
but possible.  I am not at all enthusiastic about making the code unreadable
and buggy to optimize the performance of a relatively rare case.

What I MIGHT consider doing (then again, I might not), is this.  Presently,
if a user reads from /dev/tty and there are no characters waiting, FS sends
a message to the TTY task for the read, and gets a SUSPEND message back.
FS then stores the state of the process in fproc and goes back to the main
read loop.  When characters arrive, the TTY task sends FS a message, which
causes it to revive the suspended process.  The same mechanism is used for
reading on empty pipes, and will be used for open without O_NONBLOCK in
V2.0.

With relatively little effort, the disks could use this existing mechanism.
When FS sends a disk driver a message, if the disk driver didn't happen to
have the block cached internally, it could store the request in its tables,
and return a SUSPEND message immediately.  FS would react the same way as with
TTY.  I could probably even use the same code.  When the disk did the work,
it would send a message to FS, same as the TTY task now does.

This scheme would allow multiple disk requests pending at the same time, but
would not require changing FS very much.  It would require changes to those
disk drivers that wished to support this feature.  Those that didn't could
still work the old way.  If enough requests came into a driver, it could
use the elevator algorithm.

How does that sound?

I'll treat money in the next message because it will probably start a flame
war, and that way it gets a separate header.

Andy Tanenbaum (ast@cs.vu.nl)