From: Liang Ma <liangma@liangbit.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: anatoly.burakov@intel.com,
"Fengnan Chang" <changfengnan@bytedance.com>,
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: Thu, 16 Feb 2023 10:40:05 +0000 [thread overview]
Message-ID: <Y+4IBTPoAvLnpKXE@C02GF04TMD6V> (raw)
In-Reply-To: <2134819.GUh0CODmnK@thomas>
On Wed, Feb 15, 2023 at 11:10:25AM +0100, Thomas Monjalon wrote:
> Looking for reviewers please.
I will help on this.
>
> 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-16 10:40 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 [this message]
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=Y+4IBTPoAvLnpKXE@C02GF04TMD6V \
--to=liangma@liangbit.com \
--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 \
--cc=thomas@monjalon.net \
/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).