Re: [RFC/PATCH] gc: run more pre-detach operations under lock

[Jeff King <peff@peff.net>]

On Thu, Jun 20, 2019 at 12:49:32AM +0200, Ævar Arnfjörð Bjarmason wrote:

> We do it deterministically, when gc.auto thresholds et al are exceeded
> we kick one off without waiting for other stuff, if we can get the lock.
> 
> I don't think this desire to just wait a bit until all the fetches are
> complete makes sense as a special-case.
> 
> If, as you noted in <20190619190845.GD28145@sigill.intra.peff.net>, the
> desire is to reduce GC CPU use then you're better off just tweaking the
> limits upwards. Then you get that with everything, like when you run
> "commit" in a for-loop, not just this one special case of "fetch".

If you tweak the limit upwards, then you're more likely to exist in the
non-gc'd state, where reads are penalized. The gc limit is a tradeoff
between paying the price for maintenance work versus paying the price
for having an unmaintained state. So the optimal time is generally right
after you've finished a big chunk of writing, but before you've started
doing a bunch of reading (for continuous operations that are reading and
writing, there's probably some periodic crossover point every N units of
operation).

That said, I doubt it matters more than a few percent either way (if
that). So I'm fine if we want to optimize for simplicity.

-Peff