On Mon, Nov 23, 2020 at 11:22:04AM -0500, Taylor Blau wrote:
> > I think this probably mimics what alloc_nr() computes for ALLOC_GROW().
> > I wonder why buffer_grow() cannot be built around ALLOC_GROW() instead?
>
> I think that we probably could just use ALLOC_GROW() as you suggest.
> Funny enough, reading through GitHub's chat logs, apparently this is
> something that Peff and I talked about. So, 16 probably came from
> alloc_nr(), but we probably stopped short of realizing that we could
> just use ALLOC_GROW as-is.
That would probably be OK. It's a bit more aggressive, which could
matter if you have a large number of very small bitmaps. My original
goal of the "grow less aggressively" patch was to keep memory usage
down, knowing that I was going to be holding a lot of bitmaps in memory
at once. But even with micro-optimizations like this, it turned out to
be far too big in practice (and hence Stolee's work on top to reduce the
total number we hold at once).
> @@ -33,12 +34,7 @@ static inline size_t max_size(size_t a, size_t b)
> static inline void buffer_grow(struct ewah_bitmap *self, size_t new_size)
> {
> size_t rlw_offset = (uint8_t *)self->rlw - (uint8_t *)self->buffer;
> -
> - if (self->alloc_size >= new_size)
> - return;
> -
> - self->alloc_size = new_size;
> - REALLOC_ARRAY(self->buffer, self->alloc_size);
> + ALLOC_GROW(self->buffer, new_size, self->alloc_size);
> self->rlw = self->buffer + (rlw_offset / sizeof(eword_t));
> }
I think the real test would be measuring the peak heap of the series as
you posted it in v2, and this version replacing this patch (and the
"grow less aggressively" one) with ALLOC_GROW(). On something big, like
repacking all of the torvalds/linux or git/git fork networks.
If there's no appreciable difference, then definitely I think it's worth
the simplicity of reusing ALLOC_GROW().
-Peff
