Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!altos!vsi1!daver!bungi.com!news
From: phil@cs.wwu.edu (Phil Nelson)
Newsgroups: comp.sys.nsc.32k
Subject: "Advanced MINIX"?
Message-ID: <9105121108.AA13562@strawberry.cs.wwu.edu>
Date: 12 May 91 11:08:46 GMT
References: <<1991May9.175138.0@ucrmath.ucr.edu>>
Sender: news@daver.bungi.com
Reply-To: phil@cs.wwu.edu
Lines: 33
Approved: news@daver.bungi.com


   X-Path: news
   From: rhyde@ucrmath.ucr.edu (randy hyde)
   Date: 9 May 91 17:51:38 GMT
   References: <<9105081100.AA13552@cs.hut.fi>>
   Reply-To: pc532@bungi.com
   Organization: University of California, Riverside
   Precedence: bulk

   Is anyone around here working on a fix for the file manager?  Excuse my
   ignorance concerning Minix on the 532, I just received and installed the
   software on a PC (soon I will get around to mailing the disk to Bruce).
   I've noticed this "single threaded file system" produces terrible response
   time in a multiprogramming environment.  Has anyone decided to attack this
   problem?  If not, that may be my first task.
   *** Randy Hyde

Well, yes and no.  Yes, the response time has been addressed by Bruce Evans
on the comp.os.minix group.  I haven't taken time to apply his fix to
1.5h, but I assume it will show similar changes to the ones Bruce E. reports
for minix-386.  His fix - - when a process unblocks have the scheduler add
it to the front of the queue instead of the tail.  It doesn't fis the
single thread problem but people report that it does make the response
time much better.

No, in that to my knowledge no one (for minix-pc, minix-st, minix-386,
minix-532, ...) is working hard to make the fs never block for a message
from a specific place.  Several people have thought about the problem
but AST says he WILL not support a multi-thread fs.  The "best" we can
hope for, and I think it would be good enough, is to never have the fs
block for a message from a specific process.  

--Phil