Re: [PATCH v2 0/5] Allocate cache entries from memory pool
- From
Stefan Beller <sbeller@google.com>
- Date
- May 3, 2018, 17:21 UTC
- Message-ID
- <CAGZ79kbyPya0igC9v5JwNTsi0TSp-sj6v5SB4MOt625+yVB-Gg@mail.gmail.com>
- In-Reply-To
- <CACsJy8C3yZ6bSZGw1d5DjwcPgHMDE7iGGUOn9SvyLmshzs9DvQ@mail.gmail.com>
On Thu, May 3, 2018 at 9:35 AM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 14 quoted lines
> On Mon, Apr 30, 2018 at 5:31 PM, Jameson Miller <jamill@microsoft.com> wrote: >> This patch series improves the performance of loading indexes by >> reducing the number of malloc() calls. Loading the index from disk is >> partly dominated by the time in malloc(), which is called for each >> index entry. This patch series reduces the number of times malloc() is >> called as part of loading the index, and instead allocates a block of >> memory upfront that is large enough to hold all of the cache entries, >> and chunks this memory itself. This change builds on [1]. > > I have only looked at the mem-pool related patches to see if > mem-pool.c is good enough to replace alloc.c. To me, it's a "yes" > after we optimize mem_pool_alloc() a bit (not that performance really > matters in alloc.c case, but that may be because it's already > blazingly fast that we never noticed about it).
alloc.c was not just about speed, but mostly about dense packing? 855419f764a (Add specialized object allocator, 2006-06-19)
To me it is also a clear yes when it comes to combining these two memory pools.