index paging and caching
Robert Collins
robertc at robertcollins.net
Fri Jul 27 04:00:25 BST 2007
On Thu, 2007-07-26 at 21:40 -0500, Martin Pool wrote:
> I'd also incline towards setting a limit on the overall cache size,
> and then trying to get the right replacement policy within that. This
> is the thing that will have the strongest effect if it's too large,
> and also the thing users could most reasonably potentially set.
I don't really want a knob for users; I want the system to allocate
enough and JustDoIt. If we have to have different commands set a knob
that will be ok but ugly.... One can spend a lifetime on cache
replacement policies trying to get them right - and some of the most
interesting are patented :(. What we have today in bzr is a full copy of
the index loaded at object access time, so any cache that is smaller
than the full size should be a step forward from what we have today.
What I care most about is that I don't pessimise any major use case
during the reduction from 'fully cached' to 'partially cached'.
> It
> may be (??) that the access pattern is quite different between file
> and metafile indexes, and so we need to arrange different replacement
> policies for them.
As I said in my sketch, I am planning separate page caches for them. If
we want to make share a single arena we can do so but that will preclude
having different replacement policies, or at least make it very
interesting harmonising them.
> Can I encourage you to add a -Dindexcache that says for example the
> overall hit and miss rate.
Already intended.
-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070727/d1623655/attachment.pgp
More information about the bazaar
mailing list