From: Jameson Miller Date: Mon, 23 Apr 2018 16:44:50 GMT Subject: Re: [PATCH v1 0/5] Allocate cache entries from memory pool Message-ID: <3ec5999c-f81d-eafb-1597-4fa93f943a6d@gmail.com> In-Reply-To: On 04/20/2018 01:49 PM, Stefan Beller wrote: >>> base-commit: cafaccae98f749ebf33495aec42ea25060de8682 >> >> I couldn't quite figure out what these five patches were based on, >> even with this line. Basing on and referring to a commit that is >> not part of our published history with "base-commit" is not all that >> useful to others. > > I'd like to second this. In the object store refactoring, I am at a point where > I'd want to migrate the memory management of {object, tree, commit, tag}.c > which currently is done in alloc.c to a memory pool, that has a dedicated > pointer to it. > > So I'd either have to refactor alloc.c to take the_repository[1] or > I'd play around with the mem_pool to manage memory in the > object layer. I guess this playing around can happen with > what is at origin/jm/mem-pool, however the life cycle management > part of the third patch[2] would allow for stopping memleaks there. > So I am interested in this series as well. > Sorry about the confusion here. This patch series can be applied to the next branch. They apply cleanly on [3]. The lifecycle functions are re-introduced in [4], which we could incorporate sooner if useful. I didn't have a consumer for the calls in the original patch series, and so deferred them until there was a caller. I would be interested to understand how the mem_pool would fit your needs, and if it is sufficient or needs modification for your use cases. > [1] proof of concept in patches nearby > https://public-inbox.org/git/20180206001749.218943-31-sbeller@google.com/ > > [2] https://public-inbox.org/git/20180417163400.3875-5-jamill@microsoft.com/ > > Thanks, > Stefan > [3] b46fe60e1d ("merge-fix/ps/test-chmtime-get", 2018-04-20) [4] https://public-inbox.org/git/20180417163400.3875-5-jamill@microsoft.com/