> > +void mem_pool_combine(struct mem_pool *dst, struct mem_pool *src) {
> > + struct mp_block *p;
> > +
> > + /* Append the blocks from src to dst */
> > + if (dst->mp_block && src->mp_block) {
> > + /*
> > + * src and dst have blocks, append
> > + * blocks from src to dst.
> > + */
> > + p = dst->mp_block;
> > + while (p->next_block)
> > + p = p->next_block;
> > +
> > + p->next_block = src->mp_block;
>
> Just being curious, but does this interact with the "we carve out only from
> the
> first block" done in step 4/8? The remaining unused space in the first block
> in
> the src pool would be wasted, which may not be such a big deal and may not
> even be worth comparing the available space in two blocks and picking a larger
> one. But we do want to decide _after_ thinking things through nevertheless.
Good question - and this is something I had thought about.
In the context of current usage, this function is currently not
used frequently. It is only used in split index with
move_cache_to_base_index and remove_split_index. In either case,
the cache_entries should already be loaded into memory, and I
don't expect a big enough difference in the amount of left over
space to make a meaningful difference.
In the general case I could see this being a bigger case.
For now, I thought the logic as is was an appropriate tradeoff. I
don't think it would be complicated to do something smarter here,
but I also didn't see much benefit in current usage. If we prefer
something else here, I can update this logic.
