Re: Direct mapped like caching

Andres,

        I think your description matches the reiserfs work and the
digest-based approaches that were recently discussed on this list.
There are minor differences here and there, but the big picture
remains the same -- remove StoreEntry and rely on other mechanisms to
detect hits/misses and manage cache store.

        I suspect that it is impossible to select the best approach at
this point. There are two many unknowns. Moreover, it is likely, IMO,
that there is no "best" approach at all; many approaches are the
"best" depending on the environment.

        The only big problem that I see is keeping old and new schemes
supported by the same Squid "core". It seems to me that a lot of
changes will be required to enable Squid to support StoreEntry-based
and StoreEntry-less approaches along with all the different modules
for file systems and such. At some point, it may be not worth it to
try to support all models/modules that ever existed or have been
proposed.

        In other words, do we really want to see Squid as a huge
collection of super-compatible-and-inter-exchangeable modules? If yes,
a *lot* of performance-unrelated work will need to be done first (and
supporting a very diverse collection of approaches will most likely
hurt performance at least a bit). If no, then compatibility and
similar arbitrary choices will need to be made to select a small
subset of the "best" modules.

$0.02,

Alex.

On Mon, 6 Nov 2000, Andres Kroonmaa wrote:

> I've been wondering sometimes, what if we drop LRU and other
> replacement policies, and implement something that is used in
> CPU-caching: like direct-mapped and set-associative caches.
>
> ...
>
> What seems attractive to me in this approach, is that we don't
> need to bother about replacement overhead, lookup overhead,
> FS overhead, memory overhead, startup overhead, (even dirty
> startups, as most disk ops are atomic). We can consider disks
> just a bunch of spindles, cheap and massive compared to anything
> else in a system.
Received on Mon Nov 06 2000 - 15:14:27 MST