ESDI caching disk controllers: Reprise

[Lyle Seaman]

bill at ssbn.WLK.COM (Bill Kennedy) writes:
...
>configuration of kernel buffers.  I think my NBUFS is either 1024 or
>2048, but you get my point.  My sar says I'm getting 90%+ hit rate
>on the kernel buffers; that would actually aggravate the LRU scheme in
>the disk controller.  Example: ps -ef is really fast when the system
>is busy and very slow when it's near idle for a long time.

This brings up an interesting question.  If both the kernel and the
controller are using the same algorithm (LRU), then there's going to
be a considerable duplication, isn't there?  Hmm, on the other hand,
the data in the controller cache will be that of the last controller
accesses, so they'll be misses on the kernel cache.  Problem is that 
when something is accessed from the controller cache, it goes into the
kernel cache, but something in the kernel cache gets thrown away,
which, by definition, was used more recently than what we just got
from the controller.  That seems to leave a hole in the algorithm.  If
only there was some way to modify the kernel cache code so it moves
buffers to the controller cache.

Also, consider paging.  When I page memory out, it goes directly to
the swap device, but not through the kernel cache.  In this case, it
goes into the controller cache, which might subvert the algorithm.  If
you're using a caching controller, might it be worthwhile to reduce
your kernel cache so as to avoid paging?. 

I guess there isn't much point in putting a caching controller on a
machine that hasn't maxed its primary memory, eh?

-- 
Lyle                      Wang             lws at comm.wang.com
508 967 2322         Lowell, MA, USA       uunet!comm.wang.com!lws