Re: [PATCH v3 0/7] allocate cache entries from memory pool
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 24, 2018, 04:55 UTC
- Message-ID
- <xmqqa7spsle1.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20180523144637.153551-1-jamill@microsoft.com>
Jameson Miller <jamill@microsoft.com> writes:
Show 6 quoted lines
> Changes from V2: > > - Tweak logic of finding available memory block for memory > allocation > > - Only search head block
Hmph. Is that because we generally do not free() a lot so once a block is filled, there is not much chance that we have reclaimed space in the block later?
Show 7 quoted lines
> - Tweaked handling of large memory allocations. > > - Large blocks now tracked in same manner as "regular" > blocks > > - Large blocks are placed at end of linked list of memory > blocks
If we are only carving out of the most recently allocated block, it seems that there is no point looking for "the end", no?
Show 5 quoted lines
> - Cache_entry type gains notion of whether it was allocated > from memory pool or not > > - Collapsed cache_entry discard logic into single > function. This should make code easier to maintain
That certainly should be safer to have a back-pointer pointing to which pool each entry came from, but doesn't it result in memory bloat?