jkh@meepmeep.pcs.com (Jordan K. Hubbard) (05/07/91)
Taking one of my rare sojourns into the comp.os.minix group, I noticed
today that something termed "Advanced Minix 1.5.10{D,E}" is being
bandied about.
What, in short, is it?
In broader terms, is Minix development on the PC532 progressing or
has everyone dropped it for the grail represented by Mach 3.0?
As a MINIX licencee, I still remain curious about advances on this
front.
Jordanphil@cs.wwu.edu (Phil Nelson) (05/08/91)
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
Taking one of my rare sojourns into the comp.os.minix group, I noticed
today that something termed "Advanced Minix 1.5.10{D,E}" is being
bandied about.
What, in short, is it?
Well, I haven't heard of 1.5.10{D,E} but I have seen Minix 1.6.11 and
1.6.15. The 1.6 stuff is still in "beta test" and has been sent out
only to the minix beta group. I am on the minix beta mailing list so
I have seen both 1.6 versions and all the fixes and problems. It has
several nice extensions over 1.5.10. To list a couple, Large file
systems (2GB+) AND File locking. It is also supposed to be POSIX
compatable.
In broader terms, is Minix development on the PC532 progressing or
has everyone dropped it for the grail represented by Mach 3.0?
As one who has invested time in making minix work better for me, I don't
see minix going away in the near future. Both GNU OS and BSD4.4 (if it
is completely free) are still in the future. Also, many people do not
have AT&T source licenses and can not use the UNIX server on Mach 3.0.
If I was to make a good guess, I think that minix 1.6.? will be running
on PC532s before GNU OS or BSD4.4. Since Mach 3.0 has (is being) ported
to the PC532, when the GNU OS (or BSD4.4) arrives, it should not take much
time to get them running. :-)
I would like my machine running BSD4.4 but I don't want to jump the
minix ship before I have a free or cheep solution that is better than
minix.
On a slightly different subject, I am interested in how many people
have upgraded to minix 1.5h? Please drop me a line if you are
running minix 1.5h.
Thanks
Philjkp@sauna.hut.fi (Jyrki Kuoppala) (05/08/91)
In article <9105071838.AA09447@strawberry.cs.wwu.edu> you write: >On a slightly different subject, I am interested in how many people >have upgraded to minix 1.5h? Please drop me a line if you are >running minix 1.5h. I'm running the hybrid. //Jyrki
rhyde@ucrmath.ucr.edu (randy hyde) (05/10/91)
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
phil@cs.wwu.edu (Phil Nelson) (05/12/91)
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
culberts> (05/15/91)
> 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. This topic comes up frequently. While I am not working on an FS fix, I have thought a lot about it and I even wrote a few paragraphs which describe how I would like to see FS fixed. Sometime I would like to implement my FS fix but if you find time to take a crack at it before I do, by all means go for it! Bruce Culbertson ---------------------------------------------------------------- FS works on one system call at a time (except for reads and writes to pipes and tty's). So, suppose cc forks and execs cc1. MM sends a read to FS to load the ~300K binary. The read takes several seconds. Meanwhile, suppose you are in an editor or shell which uses RAW mode (what, you're not using ed and sh?). No characters you type will be echoed during the several seconds that it takes to load cc1. This is annoying and does not make efficient use of our computing resources. A lot of people have suggested a multi-threaded FS as a solution to this problem. I am very much opposed to this. I -do- think FS has a problem and I would like to see it fixed (and, by the way, MM has a similar problem). However, "multi-threaded" is a particular solution to the problem and I think it is the wrong solution. There are a lot of ways to provide concurrency and to protect resources against concurrent access. Unix lets multiple threads execute the OS code and uses "sleeping on addresses" to protect its resources. Unix's scheme works, of course, but it is by no means the only way to build an OS. Minix uses a different scheme: it protects its resources by letting just one thread have access to each of them. (Granted, there are some exceptions.) There is nothing wrong with Minix's concurrency control mechanism; the problem occurs at a higher level in the FS code. FS divides the work it needs to do into pieces which are too big. For example, FS treats a read system call as a single indivisible piece of work which it processes to completion before making progress on other system calls. This piece of work is too big because FS may need to block in the middle of the read to wait for a disk operation. When FS blocks for a disk operation, it does not make progress on other work it could be doing. A read can be thought of as a bunch of sub-tasks: the work that needs to be done before the first disk operation, the work that needs to be done between disk operations, and the work that is needed after the last disk operation. Between each of these sub-tasks, FS needs to check to see if there is other work it could be doing. Currently, FS does not check for other work and this is the problem. I think there is a way to fix the FS problem which does not require a major rewrite of FS, does not introduce any new and redundant concurrency control mechanisms, and minimizes the number of obscure new ways for Minix to deadlock. My solution is patterned after the mechanism which allows CISC computers to interrupt string instructions. CISC computers execute each iteration of a string instruction as though it were the first iteration. All pointers and counters are updated and written back to the CPU registers at the end of each iteration. This makes it possible to interrupt the string instructions without a ton of special case microcode to save the state of the instruction. On return from an interrupt, the processing of a string instruction is the same regardless of whether some iterations have already executed. This idea could be applied to FS. Suppose FS needs to process a read. FS would save a copy of the system call message in its process table. The message is sufficient to maintain the state of the processing of the system call. In general, a sequence of disk blocks must be accessed to process the read. First, assume one of the blocks is present in the buffer cache. Data is copied from the buffer cache to the user's space and the count and pointers are updated in the copy of the system call message. If the count becomes zero, the user process can be restarted by sending it a reply message. Otherwise, the read system call can be placed on the end of a queue of work which FS is working on. On the other hand, suppose the block was not in the buffer cache. FS does a certain amount of processing before querying the cache and is many levels deep in nested subroutines when it discovers it must do a disk operation. When FS finds that the block is not in the cache, it first starts the disk operation by sending a message to the disk driver. Next, it places the read call on a queue of calls to be restarted when the block becomes valid. Finally, it longjmp's to pop all the subroutines off its stack, thereby forgetting that it has ever started processing the read call! The longjmp returns FS to its top level loop. When a message arrives indicating the disk operation is complete, the queue of calls waiting on the block is moved to the end of the queue of work which FS needs to do. The next time FS tries to process the read, it will find the block in the buffer cache, which is the case I described in the previous paragraph. Notice that when FS finds a read call on its queue of work to do, it does not need to know if it has already done some work on behalf of the call. It treats the call the same, regardless. This eliminates the need for a complicated state table and minimizes the changes which need to be made to FS. At first, it appears that this approach requires a lot of redundant work. For example, FS fetches the inode of the file before each block is read. In fact, it is necessary to repeat this processing, regardless of the FS implementation, because FS must check that another user has not removed the file in the middle of the processing of the read call. The new top-level FS loop would look like this: while (1) { while (work queue is not empty) process work on queue; receive (Message); place Message at end of work queue; } While I have left out some of the details for this FS modification, I hope it is clear that it does not change the majority of the code. It adds a few fields to the data structures in the buffer cache and FS process table. It requires some changes to FS's top level loop and it requires changes at the point where the current FS does a send-receive to block for a disk operation. With careful coding, it might even be possible to make the changes unobtrusive enough to overcome Dr. Tanenbaum's objections to fixing FS.
bdale@col.hp.com (Bdale Garbee) (05/17/91)
> With careful coding, it might even be > possible to make the changes unobtrusive enough to overcome Dr. > Tanenbaum's objections to fixing FS. When you first explained this scheme to me last year, Bruce, this was probably the hottest selling point in my mind. The solution you propose seems simple enough, yet efficient enough, to be both very useable and not difficult to maintain. Bdale