>
> > We debated several approaches for what to do here
>
> it would be awesome if the list could participate in the discussion even if
> only
> read-only.
A bit of delay in my response here, but I like the suggestion. here is a
summary of
some approaches I considered:
1) Do not include any i
>
> The memory pool design makes some tradeoffs. It is not meant to
> be completely replace malloc / free as a general purpose
> allocator, but rather used in scenarios where the benefit (faster
> allocations, lower bookkeeping overhead) is worth the
> tradeoffs (not able to free individual allocat
On Wed, May 23, 2018 at 7:47 AM, Jameson Miller wrote:
> Changes from V2:
>
> - Tweak logic of finding available memory block for memory
> allocation
>
> - Only search head block
>
> - Tweaked handling of large memory allocations.
>
> - Large blocks no
> -Original Message-
> From: Junio C Hamano On Behalf Of Junio C Hamano
> Sent: Thursday, May 24, 2018 12:55 AM
> To: Jameson Miller
> Cc: git@vger.kernel.org; pclo...@gmail.com; jonathanta...@google.com;
> sbel...@google.com; peart...@gmail.com
> Subject: Re: [P
Jameson Miller 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 ha
Changes from V2:
- Tweak logic of finding available memory block for memory
allocation
- Only search head block
- Tweaked handling of large memory allocations.
- Large blocks now tracked in same manner as "regular"
6 matches
Mail list logo