Re: [PATCH v2] index-pack: retain child bases in delta cache

From: Jeff King <peff@peff.net>
Date: Jun 2, 2026, 06:45 UTC
Message-ID: <20260602064519.GD695568@coredump.intra.peff.net>
In-Reply-To: <pull.2131.v2.git.1780330402264.gitgitgadget@gmail.com>

On Mon, Jun 01, 2026 at 04:13:21PM +0000, Arijit Banerjee via GitGitGadget wrote:

Show 13 quoted lines

> When resolving a delta whose result has children of its own,
> index-pack adds the result to work_head, accounts its data in
> base_cache_used, and calls prune_base_data(). It then immediately frees
> that same data.
> 
> This bypasses the existing delta base cache policy and can force later
> descendants to reconstruct the queued base again. Let the existing
> delta_base_cache_limit pruning policy decide whether to keep or evict
> the data instead.
> 
> This does not add a new cache or increase the cache limit. The object
> data is already accounted in base_cache_used before prune_base_data()
> runs, and the existing pruning and base cleanup paths still release it.

That explanation makes sense, but I'm left with one question/concern. Dropping the data for a base makes sense when we are "done" with it, because we know we won't need it anymore and it leaves more room in the cache for things we do care about.

The problem here is that the current notion of "done" is not correct. Imagine we have delta chains "A -> B -> C" and "A -> D -> F". We are totally done with A when we have resolved both B and D, but if I understand correctly, we currently throw it away after just resolving B.

Your patch never throws it away, and just waits for it to get evicted from the cache due to memory pressure. But could we realize the moment when B and D have both finished using it, and evict it then? That makes it more likely for us to keep something useful in the cache when there is pressure.

I'm not sure how hard that would be in practice, or how much it would help (the base cache works in list order, so I think it might naturally be a sort of LRU?).

-Peff