Xref: utzoo comp.protocols.nfs:1956 comp.arch:21433 Path: utzoo!news-server.csri.toronto.edu!rutgers!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.protocols.nfs,comp.arch Subject: Re: Incremental sync()s and using disk idle time Message-ID: <19838@cbmvax.commodore.com> Date: 13 Mar 91 23:54:46 GMT References: <28975@cs.yale.edu> <1991Mar12.202238.19586@zoo.toronto.edu> <3254@crdos1.crd.ge.COM> Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Organization: Commodore, West Chester, PA Lines: 37 In article <3254@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) 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. I agree also that FS code should be kept in the main CPU. Device- handling code, though, should be pushed off as much as possible into smart devices or auxiliary processors. A good modern example of this is the NCR 53c700/710. These scsi chips are essentially scsi-processors. They can take a major amount of interrupt and bus-twiddling code off of the main processor, they can handle gather/scatter, they can bus-master, they can process queues of requests, etc. They only interrupt the main processor on IO completion or on nasty errors. Perhaps my 100 mips super-mega-pipelined processor might be able to execute some of the code faster. But it has to talk to an IO chip that has a maximum access speed far slower than the processor; it has to handle a bunch of interrupts, it requires more instructions to deal with things like state transitions, etc, etc. While it could be happily executing some user process trying to do something, while a smart IO device like the 53c710 is handling a series of IO requests. IO is far less influenced by processor speed than many things - interrupt speed and the number of interrupts are often more important (assuming some level of DMA in hardware). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)