pzl@hjuxa.UUCP (04/17/87)
Has anyone gotten more than one user running on minix. If so, How does it do? (perhaps compared to 2-3 user Xenix on a PC) -- -------------------------------------------------------- |Mr. Rem. |{anywhere}!{clyde,cuuxb,decvax,ihnp4}!hjuxa!pzl --------------------------------------------------------
go@orstcs.cs.ORST.EDU (04/20/87)
Re: multi-user minix "feel": As I am doing lots of things to Minix, I haven't gotten around to creating a serial-driver yet, so real "multi-terminal" minix hasn't happened yet. However, I have been running background jobs to do compiles while I edit, and can report on this aspect. To make this possible, I #ifdef'd my system to exclude the ram-disk initialization (made it length 0) so no system memory was stolen -- /dev/mem /dev/kmem and /dev/null were left in -- just changed the length of /dev/ram. Anyway, with one "real" job running -- lots of disk I/O, Minix gets real sluggish. This is probably due to the bottle-neck in FS: FS blocks on the message to the driver for disk I/O and cannot service *any* other requests -- including terminal I/O. For my money, this has got to change. I plan on (this is somewhat half-baked yet, so don't tell me it's *impossible* - let me find it out for myself) creating multiple instantiations of FS -- essentially one for each major type of device. Each instantiation would use the same code, but get a separate stack and BSS section. The current FS "driver" module that scans messages would continue as is for each new instantiation, but a new one would be added to be the user interface for FS. It would, as the current one does, wait for user messages. When one was read it would dispatch it to the appropriate FSx for service. It would then go back and wait for more messages. The FSx routine would respond to the caller (main FS) when service was finished. The main FS would receive the response message, just like from a user. It would decide if the new message were a response or another request. If a response, it would respond to the appropriate user and that would be that. This technique has been used before -- last summer I worked on a team using VRTX (multitasking kernel for imbedded systems) and used this same technique to create server processes for a bunch of process-control thingies. VRTX has queues very much similar (in theory) to Minix's messages and I used several queues to make these multiple level of servers work. Problems with above: Minix can queue messages, but uses the PCB of the caller as the queue element when the recipient is not waiting for a message. For my idea to work, the main FS must have a queuable thing it can send to the next layer FSx for each new user request. My main goal is to *NEVER* block FS -- only the user and each instantiation of FSx (the actual FS server). This means that if a second request comes in (say) for the HD, when a current request is in service, the additional queued request to FSx for the HD must not block FS. Diagramatically: Current Minix My idea <user> <user> | | FS FS / | \ / | \ HD FD ... FS1 FS2 ... FSn | | | | chars HD FD mem <chars> is all character special devices -- those that return only "as much as is available" on read/write calls. They block in a special way. <HD> is the hard disk and <FD> is the floppy disk. An extrapolation (I'll probably use) is to create one <HD> FS and <FD> FS for each "unit" available on the hd and fd controller. This will allow (assuming suitable controller semaphores) "overlapped" seeks and other "simultaneaous" controller/device options. <mem> is the non-blocking memory devices -- /dev/mem /dev/kmem /dev/ram and /dev/null. As I said, this is still half-baked. I welcome comments (preferably constructive.) And yes, I write these kinds of programs for a living, so am not intimidated by device drivers, interrupts, etc. The system I mentioned above (VRTX based) had well over 100 processes resident -- most were tiny servers, but the organization was made it possible to add/subtract devices easily. If anyone else is experimenting along these lines, let's put our heads together. Minix is one of the best designed systems of its sort I have ever run across. If I do nothing else, I plan on trying out ideas no one would ever pay me to try :-). Minix may lack performance now, but there is no reason why it has to remain that way. And in general, let's forget that Minix only runs on toy computers. Its organization will allow for effective use of much larger machines. So hey! Let's get to it! Gary Oliver ...!hplabs!hp-pcd!orstcs!go (Until they pull my plug)