From: Thomas Monjalon <thomas@monjalon.net>
To: anatoly.burakov@intel.com, Fengnan Chang <changfengnan@bytedance.com>
Cc: dev@dpdk.org, rsanford@akamai.com, bruce.richardson@intel.com,
"Morten Brørup" <mb@smartsharesystems.com>,
maxime.coquelin@redhat.com, david.marchand@redhat.com,
jerinj@marvell.com, honnappa.nagarahalli@arm.com
Subject: Re: [PATCH] malloc: fix malloc performance may becomes worse as the number of malloc increases
Date: Wed, 15 Feb 2023 11:10:25 +0100 [thread overview]
Message-ID: <2134819.GUh0CODmnK@thomas> (raw)
In-Reply-To: <20230210063022.52171-1-changfengnan@bytedance.com>
Looking for reviewers please.
10/02/2023 07:30, Fengnan Chang:
> Here is a simple test case:
> "
> uint64_t entry_time, time;
> size_t size = 4096;
> unsigned align = 4096;
> for (int j = 0; j < 10; j++) {
> entry_time = rte_get_timer_cycles();
> for (int i = 0; i < 2000; i++) {
> rte_malloc(NULL, size, align);
> }
> time = (rte_get_timer_cycles()-entry_time) * 1000000 /
> rte_get_timer_hz();
> printf("total open time %lu avg time %lu\n", time, time/2000);
> }
> "
>
> Single rte_malloc cost time may becomes wrose as the number of malloc
> increases, In my env, first round avg time is 15us, second is 44us,
> third is 77us, fourth is 168us...
>
> The reason is,in the malloc process, malloc_elem_alloc may split new_elem
> if there have too much free space after new_elem, and insert the trailer
> into freelist. When alloc 4k with align 4k, the trailer very likely insert
> to free_head[2] again, it makes free_head[2] longer. when alloc 4k again,
> it will search free_head[2] from begin, with the number of malloc increases,
> search free_head[2] need more time, so the performance will become worse.
> Same problem will also occurs in alloc 64k with align 64k, but if alloc
> 4k with align 64, doesn't have this problem.
>
> Fix this by adjust free_head list size range, make free_head[3] hold
> elements which bigger or equal 4k, free_head[4] hold elements which bigger
> or equal 16k.
> In terms of probabilities, when alloc 4k or 16k, the probability of finding
> a suitable elem from a larger size list is greater than from a smaller
> size list.
>
> Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>
> ---
> lib/eal/common/malloc_elem.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/lib/eal/common/malloc_elem.c b/lib/eal/common/malloc_elem.c
> index 83f05497cc..35a2313d04 100644
> --- a/lib/eal/common/malloc_elem.c
> +++ b/lib/eal/common/malloc_elem.c
> @@ -367,11 +367,11 @@ prev_elem_is_adjacent(struct malloc_elem *elem)
> * containing larger elements.
> *
> * Example element size ranges for a heap with five free lists:
> - * heap->free_head[0] - (0 , 2^8]
> - * heap->free_head[1] - (2^8 , 2^10]
> - * heap->free_head[2] - (2^10 ,2^12]
> - * heap->free_head[3] - (2^12, 2^14]
> - * heap->free_head[4] - (2^14, MAX_SIZE]
> + * heap->free_head[0] - (0 , 2^8)
> + * heap->free_head[1] - [2^8 , 2^10)
> + * heap->free_head[2] - [2^10 ,2^12)
> + * heap->free_head[3] - [2^12, 2^14)
> + * heap->free_head[4] - [2^14, MAX_SIZE]
> */
> size_t
> malloc_elem_free_list_index(size_t size)
> @@ -385,8 +385,8 @@ malloc_elem_free_list_index(size_t size)
> if (size <= (1UL << MALLOC_MINSIZE_LOG2))
> return 0;
>
> - /* Find next power of 2 >= size. */
> - log2 = sizeof(size) * 8 - __builtin_clzl(size - 1);
> + /* Find next power of 2 > size. */
> + log2 = sizeof(size) * 8 - __builtin_clzl(size);
>
> /* Compute freelist index, based on log2(size). */
> index = (log2 - MALLOC_MINSIZE_LOG2 + MALLOC_LOG2_INCREMENT - 1) /
>
next prev parent reply other threads:[~2023-02-15 10:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 6:30 [PATCH] malloc: fix malloc performance may becomes worse as the number of malloc increases Fengnan Chang
2023-02-15 10:10 ` Thomas Monjalon [this message]
2023-02-15 11:10 ` Morten Brørup
2023-02-15 17:16 ` Stephen Hemminger
2023-02-16 2:54 ` [External] " Fengnan Chang
2023-02-16 14:02 ` Liang Ma
2023-02-17 2:14 ` [External] " Fengnan Chang
2023-02-16 10:40 ` Liang Ma
2023-02-20 10:59 ` David Marchand
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2134819.GUh0CODmnK@thomas \
--to=thomas@monjalon.net \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=changfengnan@bytedance.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=maxime.coquelin@redhat.com \
--cc=mb@smartsharesystems.com \
--cc=rsanford@akamai.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.