From: Jameson Miller <jamill@microsoft.com>
To: Stefan Beller <sbeller@google.com>, Duy Nguyen <pclouds@gmail.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
"gitster@pobox.com" <gitster@pobox.com>,
"jonathantanmy@google.com" <jonathantanmy@google.com>
Subject: RE: [PATCH v2 0/5] Allocate cache entries from memory pool
Date: Thu, 3 May 2018 21:13:16 +0000 [thread overview]
Message-ID: <BL0PR2101MB1106BA184260609DA69988A6CE870@BL0PR2101MB1106.namprd21.prod.outlook.com> (raw)
In-Reply-To: <CAGZ79kb1K9iysibzmn2SUfyTayXOn97wTsoL4s557j+_ievkBA@mail.gmail.com>
> -----Original Message-----
> From: git-owner@vger.kernel.org <git-owner@vger.kernel.org> On Behalf Of
> Stefan Beller
> Sent: Thursday, May 3, 2018 4:59 PM
> To: Duy Nguyen <pclouds@gmail.com>
> Cc: Jameson Miller <jamill@microsoft.com>; git@vger.kernel.org;
> gitster@pobox.com; jonathantanmy@google.com
> Subject: Re: [PATCH v2 0/5] Allocate cache entries from memory pool
>
> On Thu, May 3, 2018 at 12:17 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> >
> >> To me it is also a clear yes when it comes to combining these two
> >> memory pools.
> >
> > I also did not notice that jm/mem-pool already landed in master.
>
> Oh, thanks for telling! Now that I look at it, I am doubting it;
>
> The reason for my doubt is the potential quadratic behavior for new allocations,
> in mem_pool_alloc() we walk all mp_blocks to see if we can fit the requested
> allocation in one of the later blocks.
> So if we call mem_pool_alloc a million times, we get a O(n) mp_blocks which
> we'd have to walk in each call.
With the current design, when a new mp_block is allocated, it is
placed at the head of the linked list. This means that the most
recently allocated mp_block is the 1st block that is
searched. The *vast* majority of allocations should be fulfilled
from this 1st block. It is only when the block is full that we
search other mp_blocks in the list. If this is a concern, I think
we have a couple low cost options to mitigate it (maybe a flag to
control whether we search past the 1st mp_block for space, or
logic to move blocks out of the search queue when they are
full or fall below a threshold for available space).
If this is of interest, I could contribute a patch to enable one
of these behaviors?
>
> However in alloc.c we do know that a slab is full as soon as we look take the
> next slab. That is the beauty of knowing 'len' at construction time of the
> allocator.
>
> So I guess I'll just re-use the mp_block and introduce another struct
> fixed_sized_mem_pool, which will not look into other mp_blocks but the
> current.
>
>
> > Have
> > you tried measure (both memory usage and allocation speed) of it and
> > alloc.c?
>
> No, I was about to, but then started reading the code in an attempt to replace
> alloc.c by a mempool and saw the quadratic behavior.
>
> > Just take some big repo as an example and do count-objects -v to see
> > how many blobs/trees/commits it has, then allocate the same amount
> > with both alloc.c and mem-pool.c and measure both speed/mem.
> > I'm pretty sure you're right that mem-pool.c is a clear yes. I was
> > just being more conservative because we do (slightly) change
> > allocator's behavior when we make the switch. But it's also very
> > likely that any performance difference will be insignificant.
> >
> > I'm asking this because if mem-pool.c is a clear winner, you can start
> > to update you series to use it now and kill alloc.c in the process.
>
> I'll implement the fixed_sized_mem_pool and take some measurements.
>
> >
> > PS. Is Jeff back yet?
>
> His last email on the public list is Apr 10th, stating that he'll be offline for "a few
> weeks", in <20180406175349.GB32228@sigill.intra.peff.net> he said the
> vacation part is 3 weeks. So I think he is done with vacation and is just hiding to
> figure out a nice comeback. ;-)
>
> > I'm sure Junio is listening and all but I'm afraid he's too busy being
> > a maintainer so Jeff's opinion in this area is really valuable. He has
> > all the fun and weird use cases to play with at github.
>
> ok. I'll cc him for these patches.
>
> Thanks,
> Stefan
next prev parent reply other threads:[~2018-05-03 21:13 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-17 16:34 [PATCH v1 0/5] Allocate cache entries from memory pool Jameson Miller
2018-04-17 16:34 ` Jameson Miller
2018-04-17 16:34 ` [PATCH v1 1/5] read-cache: teach refresh_cache_entry to take istate Jameson Miller
2018-04-17 19:00 ` Ben Peart
2018-04-17 16:34 ` [PATCH v1 2/5] Add an API creating / discarding cache_entry structs Jameson Miller
2018-04-17 23:11 ` Ben Peart
2018-04-17 16:34 ` [PATCH v1 3/5] mem-pool: fill out functionality Jameson Miller
2018-04-20 23:21 ` Jonathan Tan
2018-04-23 17:27 ` Jameson Miller
2018-04-23 17:49 ` Jonathan Tan
2018-04-23 18:20 ` Jameson Miller
2018-04-17 16:34 ` [PATCH v1 4/5] Allocate cache entries from memory pools Jameson Miller
2018-04-17 16:34 ` [PATCH v1 5/5] Add optional memory validations around cache_entry lifecyle Jameson Miller
2018-04-17 18:39 ` [PATCH v1 0/5] Allocate cache entries from memory pool Ben Peart
2018-04-23 14:09 ` Jameson Miller
2018-04-18 4:49 ` Junio C Hamano
2018-04-20 17:49 ` Stefan Beller
2018-04-23 16:44 ` Jameson Miller
2018-04-23 17:18 ` Stefan Beller
2018-04-23 16:19 ` Jameson Miller
2018-04-20 23:34 ` Jonathan Tan
2018-04-23 17:14 ` Jameson Miller
2018-04-30 15:31 ` [PATCH v2 " Jameson Miller
2018-04-30 15:31 ` [PATCH v2 1/5] read-cache: teach refresh_cache_entry() to take istate Jameson Miller
2018-04-30 15:31 ` [PATCH v2 2/5] block alloc: add lifecycle APIs for cache_entry structs Jameson Miller
2018-04-30 15:31 ` [PATCH v2 3/5] mem-pool: fill out functionality Jameson Miller
2018-04-30 21:42 ` Stefan Beller
2018-05-01 15:43 ` Jameson Miller
2018-05-03 16:18 ` Duy Nguyen
2018-04-30 15:31 ` [PATCH v2 4/5] block alloc: allocate cache entries from mem_pool Jameson Miller
2018-04-30 15:31 ` [PATCH v2 5/5] block alloc: add validations around cache_entry lifecyle Jameson Miller
2018-05-03 16:28 ` Duy Nguyen
2018-05-03 16:35 ` [PATCH v2 0/5] Allocate cache entries from memory pool Duy Nguyen
2018-05-03 17:21 ` Stefan Beller
2018-05-03 19:17 ` Duy Nguyen
2018-05-03 20:58 ` Stefan Beller
2018-05-03 21:13 ` Jameson Miller [this message]
2018-05-03 22:18 ` [PATCH] alloc.c: replace alloc by mempool Stefan Beller
2018-05-04 16:33 ` Duy Nguyen
2018-05-08 0:37 ` Junio C Hamano
2018-05-08 0:44 ` Stefan Beller
2018-05-08 1:07 ` Junio C Hamano
2018-05-23 14:47 ` [PATCH v3 0/7] allocate cache entries from memory pool Jameson Miller
2018-05-23 14:47 ` [PATCH v3 1/7] read-cache: teach refresh_cache_entry() to take istate Jameson Miller
2018-05-25 22:54 ` Stefan Beller
2018-05-23 14:47 ` [PATCH v3 2/7] block alloc: add lifecycle APIs for cache_entry structs Jameson Miller
2018-05-24 4:52 ` Junio C Hamano
2018-05-24 14:47 ` Jameson Miller
2018-05-23 14:47 ` [PATCH v3 3/7] mem-pool: only search head block for available space Jameson Miller
2018-05-23 14:47 ` [PATCH v3 4/7] mem-pool: add lifecycle management functions Jameson Miller
2018-05-23 14:47 ` [PATCH v3 5/7] mem-pool: fill out functionality Jameson Miller
2018-06-01 19:28 ` Stefan Beller
2018-05-23 14:47 ` [PATCH v3 6/7] block alloc: allocate cache entries from mem_pool Jameson Miller
2018-05-23 14:47 ` [PATCH v3 7/7] block alloc: add validations around cache_entry lifecyle Jameson Miller
2018-05-24 4:55 ` [PATCH v3 0/7] allocate cache entries from memory pool Junio C Hamano
2018-05-24 14:44 ` Jameson Miller
2018-05-25 22:53 ` Stefan Beller
2018-06-20 20:41 ` Jameson Miller
2018-05-25 22:41 ` Stefan Beller
2018-06-20 20:17 ` [PATCH v4 0/8] Allocate cache entries from mem_pool Jameson Miller
2018-06-20 20:17 ` [PATCH v4 1/8] read-cache: teach refresh_cache_entry() to take istate Jameson Miller
2018-06-20 20:17 ` [PATCH v4 2/8] block alloc: add lifecycle APIs for cache_entry structs Jameson Miller
2018-06-21 21:14 ` Stefan Beller
2018-06-28 14:07 ` Jameson Miller
2018-06-20 20:17 ` [PATCH v4 3/8] mem-pool: only search head block for available space Jameson Miller
2018-06-21 21:33 ` Stefan Beller
2018-06-28 14:12 ` Jameson Miller
2018-06-20 20:17 ` [PATCH v4 4/8] mem-pool: tweak math on mp_block allocation size Jameson Miller
2018-06-20 20:17 ` [PATCH v4 5/8] mem-pool: add lifecycle management functions Jameson Miller
2018-06-20 20:17 ` [PATCH v4 6/8] mem-pool: fill out functionality Jameson Miller
2018-06-20 20:17 ` [PATCH v4 7/8] block alloc: allocate cache entries from mem_pool Jameson Miller
2018-06-20 20:17 ` [PATCH v4 8/8] block alloc: add validations around cache_entry lifecyle Jameson Miller
2018-06-28 14:00 ` [PATCH v5 0/8] Allocate cache entries from mem_pool Jameson Miller
2018-06-28 14:00 ` [PATCH v5 1/8] read-cache: teach refresh_cache_entry() to take istate Jameson Miller
2018-06-28 14:00 ` [PATCH v5 2/8] read-cache: make_cache_entry should take object_id struct Jameson Miller
2018-06-28 17:14 ` Junio C Hamano
2018-06-28 22:27 ` SZEDER Gábor
2018-06-28 14:00 ` [PATCH v5 3/8] block alloc: add lifecycle APIs for cache_entry structs Jameson Miller
2018-06-28 18:43 ` Junio C Hamano
2018-06-28 22:28 ` SZEDER Gábor
2018-06-28 14:00 ` [PATCH v5 4/8] mem-pool: only search head block for available space Jameson Miller
2018-06-28 14:00 ` [PATCH v5 5/8] mem-pool: add life cycle management functions Jameson Miller
2018-06-28 17:15 ` Junio C Hamano
2018-06-28 14:00 ` [PATCH v5 6/8] mem-pool: fill out functionality Jameson Miller
2018-06-28 19:09 ` Junio C Hamano
2018-07-02 18:28 ` Jameson Miller
2018-06-28 14:00 ` [PATCH v5 7/8] block alloc: allocate cache entries from mem-pool Jameson Miller
2018-06-28 14:00 ` [PATCH v5 8/8] block alloc: add validations around cache_entry lifecyle Jameson Miller
2018-07-02 19:49 ` [PATCH v6 0/8] Allocate cache entries from mem_pool Jameson Miller
2018-07-02 19:49 ` [PATCH v6 1/8] read-cache: teach refresh_cache_entry to take istate Jameson Miller
2018-07-02 19:49 ` [PATCH v6 2/8] read-cache: teach make_cache_entry to take object_id Jameson Miller
2018-07-02 21:23 ` Stefan Beller
2018-07-05 15:20 ` Jameson Miller
2018-07-02 19:49 ` [PATCH v6 3/8] block alloc: add lifecycle APIs for cache_entry structs Jameson Miller
2018-07-22 9:23 ` Duy Nguyen
2018-07-02 19:49 ` [PATCH v6 4/8] mem-pool: only search head block for available space Jameson Miller
2018-07-02 19:49 ` [PATCH v6 5/8] mem-pool: add life cycle management functions Jameson Miller
2018-07-02 19:49 ` [PATCH v6 6/8] mem-pool: fill out functionality Jameson Miller
2018-07-02 19:49 ` [PATCH v6 7/8] block alloc: allocate cache entries from mem_pool Jameson Miller
2018-07-02 19:49 ` [PATCH v6 8/8] block alloc: add validations around cache_entry lifecyle Jameson Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BL0PR2101MB1106BA184260609DA69988A6CE870@BL0PR2101MB1106.namprd21.prod.outlook.com \
--to=jamill@microsoft.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=pclouds@gmail.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).