From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 24 May 2018 04:55:18 GMT
Subject: Re: [PATCH v3 0/7] allocate cache entries from memory pool
Message-ID: <xmqqa7spsle1.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180523144637.153551-1-jamill@microsoft.com>

Jameson Miller <jamill@microsoft.com> writes:

> 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?

> 	- 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?


> 	- 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?