a take at cache coherency

Csaba Henk csaba.henk at creo.hu
Tue Jan 24 09:12:13 PST 2006

On 2006-01-24, Simon 'corecode' Schubert <corecode at xxxxxxxxxxxx> wrote:
> We need to linearize the cache entries anyways now, as we can't maintain 
> a tree structure with doubly linked lists.

We don't need to linearize them. We can use the same tree layout as in
the fs hierarchy: pointers in one direction, list of neighbours in the
other direction.

If we had such a flattened version: we would either have it as a
substitute for the tree layout, or as an addendum. (I don't see which
one of these was suggested by you, so I discuss both.)

Regarding the former: I don't think it would be sufficient. While the
cache layer could get along happily with flat groups, overlays operate
with direct "x shadows y" relations, which mans we have the tree.

So, from this on I'll assume the latter: having the flat thing as an

> - have a ncp_shadowroot
> - have a ncp_shadowlink which maintains a single linked list to all 
> other entries in the group
> - this way we don't have to run through all entries every time when 
> doing locking.  we just lock ncp->ncp_shadowroot->ncp_exlocks++.

So then, the ncp_shadow{root,link} fields would serve as some kind of
cache. With all the befenits and drawbacks of a cache: you can retrieve
some information immediately, but you have to take care about the
validity of cached information.

More information about the Kernel mailing list