jpp@specialix.co.uk (John Pettitt) (09/01/89)
brad@looking.on.ca (Brad Templeton) writes: >While cylinder or track caching is an eminently sensible idea that I >have been waiting to see for a long time, what is the point in the >controller or drive sotring more than that? It's faster ! >Surely it makes more sense for the OS to do all other cache duties. >Why put the 512K in your drive when you can put it in your system and >bump your cache there? Other than the CPU overhead of maintaining the >cache within the OS, I mean. I would assume the benefit from having >the cache maintained by software that knows a bit about what's going >on would outweigh this. Nope, the problem is that the writeback code in a normal *ix cache is pretty f*'d. What happens when you increase the cache to say 3 MB is that is waits until a good chunk of it is dirty that writes all the dirty pages out a sync time. This causes the disk do be effectivly dead for 10 seconds or mosre at a time, not an acceptable situation. If you use a controller like the DPT with a smaller unix cache the sync is written to the controller cache and then flushed to disk. If any reads are requested while the controller cache is being flushed these take priority so the system is not hung up for the duration. So to answere your question, adding cache to a *ix system (well Xenix and UNIX 5.3.x 386) via more buffers don't help. If the somebody was to fix the kernel code then thengs would improve greatly. >-- >Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473 -- John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR {backbone}!ukc!slxsys!jpp jpp%slxinc@uunet.uu.net jpp@specialix.co.uk Tel: +44-1-941-2564 Fax: +44-1-941-4098 Telex: 918110 SPECIX G >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
vjs@calcite.UUCP (Vernon Schryver) (09/03/89)
In article <1989Sep01.104447.9573@specialix.co.uk>, jpp@specialix.co.uk (John Pettitt) writes: > Nope, the problem is that the writeback code in a normal *ix cache > is pretty f*'d. If you say so. Async writes, sync writes, and write-behinds are a messy way to attack the problem, but one would not want to give up any of them. > What happens when you increase the cache to say > 3 MB is that is waits until a good chunk of it is dirty that writes > all the dirty pages out a sync time. That's not how the machines I've seen running SVR3 behave. Nor is it the way the bdflush() kernel process in SVR3 is coded. Many vendors in 1989 have straight SVR3 ports, or enough of SVR3 for the suits to prattle about. > If the > somebody was to fix the kernel code then thengs would improve > greatly. > -- > John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR > {backbone}!ukc!slxsys!jpp jpp%slxinc@uunet.uu.net jpp@specialix.co.uk There's always room for improvement. Vendors of "real" UNIX computers (i.e. not just PC's) are doing things like "page flipping". For many applications that makes large caches in the either the kernel or controllers suboptimal. Vernon Schryver vjs@calcite.uucp ...{pyramid,sgi}!calcite!vjs