Cache controllers, can Xenix use them?
Wm. Brian McCane
news at brian386.UUCP
Fri Mar 17 15:13:07 AEST 1989
In article <1425 at mtunb.ATT.COM> jcm at mtunb.UUCP (was-John McMillan) writes:
> Caches usually require kernel software for:
> 1) Boot-time checkout (validation);
> 2) Defective cache shutdown/workaround;
> 3) Context-switch flushing;
> 4) Memory-mapped hardware cache-BLOCKING;
> 5) DMA-overlapped page flushing/blocking;
> 6) Text-loading cache-flushing (split text & data caching);
> 7) ... ok, my recollections are fading....
>
To quote Bill Murray "Whooooa nice shootin' there Tex!" But I'm a little
concerned as to it's accuracy. Admitted I don't do hardware or Unix kernels
for a living, but I know a little.
Cache checking should be done in the power up routines just like the
keyboard. And if it is defective, the system probably won't boot,
since I believe cache off on most systems means it doesn't cache, instead
it just passes the data blindly.
>From what I remember of the specs (their at work, I'm not :-),
the cache doesn't care about the context or any such noise. Instead,
it keeps track of the absolute address requested by the '386, and can
retrieve the date in 16 byte blocks, for later use. The data is kept using
an modified Least Recently Used algorithm. The biggest problem, is that
some operations such as compressing/decompressing files, or any operations
where large amounts of PHYSICAL RAM are used reduce the caches usefulness
to 0. Any access by the CPU to ram including swaps to disk (I'm not
sure about DMA but I think it works too), are simply kept track of and the
new contents that are stored in these locations is used.
brian
--
Wm. Brian McCane | Life is full of doors that won't open
| when you knock, equally spaced amid
Disclaimer: I don't think they even | those that open when you don't want
admit I work here. | them to. - Roger Zelazny "Blood of Amber"
More information about the Comp.unix.questions
mailing list