From: David Marchand <david.marchand@redhat.com>
To: Fengnan Chang <changfengnan@bytedance.com>
Cc: anatoly.burakov@intel.com, rsanford@akamai.com, dev@dpdk.org,
"Morten Brørup" <mb@smartsharesystems.com>,
"Liang Ma" <liangma@liangbit.com>,
"Stephen Hemminger" <stephen@networkplumber.org>
Subject: Re: [PATCH] malloc: fix malloc performance may becomes worse as the number of malloc increases
Date: Mon, 20 Feb 2023 11:59:11 +0100 [thread overview]
Message-ID: <CAJFAV8x5k55jH0A_BHN9jxA1m-3o08tKr7RbCesvVL7o4MKgGQ@mail.gmail.com> (raw)
In-Reply-To: <20230210063022.52171-1-changfengnan@bytedance.com>
On Fri, Feb 10, 2023 at 7:30 AM Fengnan Chang
<changfengnan@bytedance.com> wrote:
>
> 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>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
The change looks simple enough.
I see an improvement with the (verbatim) malloc_perf_autotest unit
tests for 1M allocations too.
Let's take this change now and see how it goes with -rc1 testing.
Applied, thanks.
--
David Marchand
prev parent reply other threads:[~2023-02-20 10:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 6:30 Fengnan Chang
2023-02-15 10:10 ` Thomas Monjalon
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 [this message]
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=CAJFAV8x5k55jH0A_BHN9jxA1m-3o08tKr7RbCesvVL7o4MKgGQ@mail.gmail.com \
--to=david.marchand@redhat.com \
--cc=anatoly.burakov@intel.com \
--cc=changfengnan@bytedance.com \
--cc=dev@dpdk.org \
--cc=liangma@liangbit.com \
--cc=mb@smartsharesystems.com \
--cc=rsanford@akamai.com \
--cc=stephen@networkplumber.org \
/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 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 NNTP newsgroup(s).