ast@cs.vu.nl (Andy Tanenbaum) (08/02/90)
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)
adrie@philica.ica.philips.nl (Adrie Koolen) (08/02/90)
In article <7217@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >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. When a task issues a SUSPEND reply, it specifies the number of the user process to be suspended. When reading/writing blocks, the FS specifies itself as the process for wich I/O must be done! This brings me to the standard problem: the FS issues requests to the (block) tasks for user processes AND for the FS self. The former could be suspended but suspending the latter would require a lot of rewriting of the FS. Maybe I am a little to negative, but a stated FS doesn't seem easier or more stable than a multi-threaded FS. Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen
graham@sce.carleton.ca (Doug Graham) (08/03/90)
In <7217@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >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. Ah, I see. So *that* was the purpose of your message. >First, FS. There is no way I am ever going to muck up FS just to adding >multithreading. Hmmm, no swapping, no virtual memory, no multithreading ... I sure wish the GNU people would hurry up. I wonder what'll become of MINIX when GNU OS hits the streets? (I hope some of us are still alive to find out) >in a limited number of circumstances. MINIX is intended for personal >computers. I though MINIX was intended as a teaching system. Isn't it important that students learn how a real world OS works? Some of them might even work on one someday. >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, Try running a make in the background and doing *anything* in the foreground. I sure notice the difference. But why would anyone want to do that anyway? Why do you think so many people are concerned about improving the throughput of FS? Is it possible that they just might have noticed a problem? >but possible. I am not at all enthusiastic about making the code unreadable >and buggy to optimize the performance of a relatively rare case. Well then, *don't* make the code unreadable and buggy. (A smartass answer I know, but I really don't see why adding threads is going to create all the problems you're projecting.) > What I MIGHT consider doing (then again, I might not), is this. I realize you're a busy man, and probably don't have a lot of time to be making major changes to MINIX, but it seems to me that there are enough keen MINIX hackers out there to do the work. You only have to give the go ahead, and maybe coordinate a bit. >With relatively little effort, the disks could use this existing mechanism. [use SUSPEND and REVIVE as with TTY I/O] >How does that sound? Like you haven't thought it through. A number of people on comp.os.minix have pointed out problems with this method while you were gone. Unless you've got some secret tricks up your sleeve, I can't see how this could fail to be much more unreadable and buggy than using threads. It would also require major changes to most of FS which threads would not. -- Doug.
ast@cs.vu.nl (Andy Tanenbaum) (08/03/90)
In article <641@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) writes: >When a task issues a SUSPEND reply, it specifies the number of the user >process to be suspended. When reading/writing blocks, the FS specifies >itself as the process for wich I/O must be done! This brings me to the >standard problem: the FS issues requests to the (block) tasks for user >processes AND for the FS self. You're right. I spoke too fast. One could have FS tell the driver whether the request was on behalf of a user or on behalf of itself, and have the driver react immediately to FS's own requests, but this seems to add a lot of complexity to the drivers. I guess the conclusion is that this project gets pushed from the back burner off the rear end of the stove. Andy Tanenbaum (ast@cs.vu.nl).
brucee@runxtsa.runx.oz.au (Bruce Evans) (08/05/90)
In article <7217@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >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 This can only work for data blocks. Even then, it only solves the easy part of the problem. Suppose user1 asks for a block not in the cache and is suspended, then user2 asks for the same block. The second request must not get far as the device driver, and will require a more complicated suspension method. Note that the second request may be from a deeply nested FS function for a directory block although the first request if for a data block. -- Bruce Evans Internet: brucee@runxtsa.runx.oz.au UUCP: uunet!runxtsa.runx.oz.au!brucee (My other address (evans@ditsyda.oz.au) no longer works)
peter@ficc.ferranti.com (Peter da Silva) (08/07/90)
In article <7217@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > I am not at all enthusiastic about making the code unreadable > and buggy to optimize the performance of a relatively rare case. You mean, like anyone running a news feed? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
peter@ficc.ferranti.com (Peter da Silva) (08/09/90)
In article <888@sce.carleton.ca> graham@sce.carleton.ca (Doug Graham) writes: > I wonder what'll become of MINIX when GNU OS hits the streets? (I > hope some of us are still alive to find out) I'm beginning to think that they're planning on running EMACS standalone and calling it GNU-OS. It's 1999: "What's that?" "My new IBM SPQR-666000" "Wow! What are you running on that thing?" "X-GNU-Emacs under Mach, only requires 1.21 Gigabytes RAM and that's including the UNIX, VMS, and DOS emulator." "How fast?" "Well, Norton says it's 2.3 si, is that good?" -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>