Xref: utzoo comp.protocols.nfs:1969 comp.arch:21443
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.protocols.nfs,comp.arch
Subject: Re: Incremental sync()s and using disk idle time
Message-ID: <3265@crdos1.crd.ge.COM>
Date: 14 Mar 91 18:08:48 GMT
References: <28975@cs.yale.edu> <PCG.91Feb28195347@odin.cs.aber.ac.uk> <1991Mar12.202238.19586@zoo.toronto.edu> <3254@crdos1.crd.ge.COM> <PCG.91Mar13180706@aberdb.test.aber.ac.uk>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Followup-To: comp.protocols.nfs
Organization: GE Corp R&D Center, Schenectady NY
Lines: 38

In article <PCG.91Mar13180706@aberdb.test.aber.ac.uk> pcg@test.aber.ac.uk (Piercarlo Antonio Grandi) writes:

| 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.

  The CPU with the expensive cache, float, and maybe vector capability.
As opposed to an 8 bit CPU with integrated interrupt controller, some
parallel i/o, etc. And one or many, I can usually find better use for
their capabilities than manipulating status bytes.

| 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.

  What has decisions got to do with implementation? The CPU running the
o/s can decide how many retries (including none if there's ever a disk
that doesn't need one now and then), and what to do with the count of
retries returned by the smart controller. But to have the retries
actually done by the CPU which can do more? To what gain?

| 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.

  Remember the fastest way to do something is to avoid having to do it.
Every interrupt will require a context switch in and out of the
interrupt handler. The only real low cost way to do this is to have a
set of dedicated interrupt registers (like the 2nd register set of the
Z80), and I bet no one will suggest that a CPU should dedicate area to a
set of registers just to avoid a smart controller.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
        "Most of the VAX instructions are in microcode,
         but halt and no-op are in hardware for efficiency"