🚀 go-pugleaf

Rod May (stoke@werple.mira.net.au) wrote:

: The point is if you're going to pay for memory, give the operating system
: the chance to use it in a flexible way, depending on its workload.
: Linux will use it intelligently.
: People who buy cached disk controllers and get all excited about the
: disk bench mark test don't seem to realise that all this exciting
: I/O is pointless when the extra memory may have avoided the need for
: an I/O in the first place, eg swapping................

	Personally, I use a caching controller - and I fully realize that 
hardware caching over an ISA bus is quite a bit slower than software 
caching.  However, when using multiple operating systems, depending on 
what I'm doing, I _always_ know that I have a good, solid cache that 
cannot be corrupted by whatever application, operating system, beta 
driver, or whatever else I happen to be doing.  In addition, it's a very 
good choice after you've maxed the memory on your computer out - what do 
you do, if your application and operating system requires all the memory 
the MB can handle, and you still want a cache?
	Additionally, a caching controller doesn't need to bother with 
using CPU cycles, system RAM for the program, or anything else like that 
- it (should) all be taken care of by the CPU and\or ASIC on the 
controller board, rendering it, in my opinion, more reliable than 
software caches.  As a final point, hardware caching is something that 
the software you run doesn't even know exists, and can't tell if it 
exists or not (for all it knows, your whole hard drive could be flash 
memory with a SCSI, IDE, ESDI, MFM, RLL, or whatever interface - if it 
even knows what interface it is!), much less see any of the code 
(assuming the code would even run on the main CPU, which isn't likely in 
many cases).  Therefore, said cache doesn't conflict with any software in 
your system.
	Basically, the point is that a software cache is faster, and a 
hardware cache is truly transparent - effectively not there, as far as 
any system software goes.  
						Patrick Hall
						phall@umr.edu