Xref: utzoo comp.protocols.nfs:1966 comp.arch:21440 Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@test.aber.ac.uk (Piercarlo Antonio Grandi) Newsgroups: comp.protocols.nfs,comp.arch Subject: Re: Incremental sync()s and using disk idle time Message-ID: Date: 13 Mar 91 18:07:06 GMT References: <28975@cs.yale.edu> <1991Mar12.202238.19586@zoo.toronto.edu> <3254@crdos1.crd.ge.COM> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 62 Nntp-Posting-Host: aberdb In-reply-to: davidsen@crdos1.crd.ge.COM's message of 12 Mar 91 22:36:00 GMT On 12 Mar 91 22:36:00 GMT, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) said: davidsen> In article <1991Mar12.202238.19586@zoo.toronto.edu> davidsen> henry@zoo.toronto.edu (Henry Spencer) writes: henry> That aside, the most probable result is that your big expensive henry> main host CPU, which could undoubtedly run that code a lot henry> faster, will spend all its time waiting for the dumb little I/O henry> controller to run the filesystem. This is not a cost-effective henry> use of hardware resources. This is the low level performance side of the "down with smart devices" argument. The more important one, as you well know, but let's restate it, is that smart devices have theyir own "smart" policies that not necessairly (euphemism) are anywhere near being flexible and efficient enough. In other words, system performance should be treated as a whole, it cannot be achieved by building assumptions into each component of the system. The extreme example are those caching controllers that have the structure of a DOS volume built into their optimization patterns... davidsen> What I can't see is how anyone can feel that the main CPU davidsen> should be wasted in error logging and retries, bad sector davidsen> mapping, and handling multiple interrupts. Ahhhh, but then who should handle them? The CPU on the controller, of course. The real *performance* question then is not about smart controller vs. dumb controller. Any architecture with asynchronous IO is a de facto multiprocessor; the question is whether some of the CPUs in a multiprocessors should be *specialized* or not, and which is the optimal power to assign to each CPU if they are specialized. You speak of "main" CPU, thus *assuming* that you have one main CPU and some "smart" slave processors. The alternative is really multiple main CPUs, whose function floats. As to the specific examples you make, diagnostics (error logging and retries, bad sector mapping) should all be done by software in the "main" CPU OS anyhow, as of all things surely assumptions on error recovery strategies should not be embedded in the drive, because different OSes may well have very different fault models and fault recovery policies. Handling command chaining (multiple interrupts) can indeed be performed fairly efficiently by the main CPU in well designed OS kernels that offer lightweight interrupt handling and threading. Unfortunately industry standard OS kernels are very poorly written, so much so that for example on a 6 MIPS 386 running System V it is faster to have command chaining handled by the 8085 on the 1542 SCSI controller. As to me, I'd rather have multiple powerful CPUs on an equal footing doing programmed IO on very stupid devices than to have smart controllers, which seems to be the idea behind Henry Spencer's thinking. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk