William A. Rowe, Jr. wrote:
[...]
>About your patch - if it goes in this direction (I simply skimmed it so far)
>then I'd be happy to apply, but it looks like we are trying to accomplish two
>different things. Since the broader 'dynamic cache' schema is where we want
>to end up (IMHO) and will invalidate the usefulness of an additional 'static
>cache' (preconstructed at boot time), I'd like to pursue one chunk of code
>that everyone can focus energy at, rather than two sets of code with their own
>debugging cycles. Of course, I could be entirely off base.
>
>What are your thoughts on these two different strategies?
>
I've definitely focused just on the static preconstruction
approach, and I've specifically avoided the dynamic caching
approach. Here's my rationale:
1. I'm not convinced that the dynamic caching technique can
be implemented without creating a scalability problem (due
to the need for mutexes around the cache).
2. From a return-on-investment perspective, the static cache
looks a lot more appealing than the dynamic cache. I.e., I
anticipate that a static cache will offer 80% of the performance
benefit of a dynamic one for 20% of the development cost. (In
particular, a static cache is a *lot* cheaper to test, because
it's not vulnerable to the race conditions that make a dynamic
cache tricky.)
What do you think?
--Brian
