bernie@metapro.DIALix.oz.au (Bernd Felsche) (03/17/91)
In <3254@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >In article <1991Mar12.202238.19586@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >| That aside, the most probable result is that your big expensive main host >| CPU, which could undoubtedly run that code a lot faster, will spend all >| its time waiting for the dumb little I/O controller to run the filesystem. >| This is not a cost-effective use of hardware resources. > This is the heart of the matter, and I agree completely. What I can't >see is how anyone can feel that the main CPU should be wasted in error >logging and retries, bad sector mapping, and handling multiple interrupts. The main overhead I have noticed is interrupt handling. Just running a streaming tape on a Motorola MVME147 causes noticeable keyboard echo delays. The SBC has an on-board SCSI controller. This has little to do with disks, but illustrates the impact on users, of having i/o handled directly by the user CPU. An intelligent device controller should isolate the main CPU from the mundane bits of controlling devices, and handle only the information requested. On the other hand, device controllers should not know anything about filesystems. IMHO that's an incredibly silly idea. Much of the previous discussion on this thread has focused of the problems of having firmware or similar running on a slave processor, sharing kernel resources. This practice flies in the face of where kernel architecture is heading; i.e. microkernel with filesystem code moved to user space. The microkernel architecture promises the flexibility to maximise performance on a wide range of machines. The penalty you pay is the process switching. The rewards include the ability to write dedicated tasks to handle special filesystems, and to dynamically expand (or shrink) system resources. Of course, in multi-processor systems, the impact of moving filesystem code to user space will be most noticeable. Although SMP kernels effectively do the same now, the nature of the filesystem is determined at the time of kernel generation, limiting its flexibility. -- Bernd Felsche, _--_|\ #include <std/disclaimer.h> Metapro Systems, / sale \ Fax: +61 9 472 3337 328 Albany Highway, \_.--._/ Phone: +61 9 362 9355 Victoria Park, Western Australia v Email: bernie@metapro.DIALix.oz.au