Caching disk controllers and 386 multiprocessor

[Piercarlo Grandi]

In article <4038 at slxsys.specialix.co.uk> jpp at slxsys.specialix.co.uk (John Pettitt) writes:

    + It seems obvious that adding 2MB of buffers is going to help somewhat. 
    + But where is the best place to put the memory, on the controller or in the 
    + kernel?
    
    From the tests I ran the DPT wins over adding 2 MB of buffers to /xenix
    (don't know about `real' unix).  The improvment gained by having more
    buffers in /xenix was not great.  I think this was mostly due to the
    cacheing code being rather old and not that well written (putting on
    flame proof suit :-).

Well, there is not much you can do to improve the caching algorithm once you
have hashed cache access. If Xenix 2.3.2 does not have it, tough; all BSDs
and later SystemVs do have it.

    The basic problem seemed to be the cache write back code:  When lots of
    buffers are added to xenix it fills almost all of them with dirty data
    then spends several seconds writing them all back and the real time
    response goes out the window.

But Unix does flush the cache to have less loss of data in the case of
crashes. In particular, "hardened" filesystems implement directory and inode
modifications with write-thru, instead of write-back, which kills the
performance of dump restores when there are many small files.

    The DPT is far better balanced in this respect and so gives a mush more
    even throughput.

Either the DPT has battery backing for its 2MBs of cache, or it is a very
dangerous proposition. Even if it has non volatile memory, it will lenghten,
possibly by much, the moment in which data is written to the disc, which
makes error reporting even more impricise than it is; and, I hope it has an
explicit flush command, if you want to be sure that disc contents actually
reflect what you think is on them.

In practice you lose with cache in the controller vs. main memory also when
you have two controllers, which is virtually a must (given that most are not
multithreading, except SCSI ones) for high performance multiuser systems.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk