From: Thomas Monjalon <thomas@monjalon.net>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: dev@dpdk.org, Ali Alnubani <alialnu@mellanox.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
Raslan Darawsheh <rasland@mellanox.com>,
stable@dpdk.org, Andrew Rybchenko <arybchenko@solarflare.com>
Subject: Re: [dpdk-dev] [PATCH v2] mempool: fix slow allocation of large mempools
Date: Mon, 20 Jan 2020 11:12:35 +0100 [thread overview]
Message-ID: <1863691.ZhSLo9btvA@xps> (raw)
In-Reply-To: <d27f108e-3689-0b63-344f-20e525a93291@solarflare.com>
17/01/2020 11:09, Andrew Rybchenko:
> On 1/17/20 1:01 PM, Olivier Matz wrote:
> > On Fri, Jan 17, 2020 at 10:51:49AM +0100, Olivier Matz wrote:
> >> When allocating a mempool which is larger than the largest
> >> available area, it can take a lot of time:
> >>
> >> a- the mempool calculate the required memory size, and tries
> >> to allocate it, it fails
> >> b- then it tries to allocate the largest available area (this
> >> does not request new huge pages)
> >> c- add this zone to the mempool, this triggers the allocation
> >> of a mem hdr, which request a new huge page
> >> d- back to a- until mempool is populated or until there is no
> >> more memory
> >>
> >> This can take a lot of time to finally fail (several minutes): in step
> >> a- it takes all available hugepages on the system, then release them
> >> after it fails.
> >>
> >> The problem appeared with commit eba11e364614 ("mempool: reduce wasted
> >> space on populate"), because smaller chunks are now allowed. Previously,
> >> it had to be at least one page size, which is not the case in step b-.
> >>
> >> To fix this, implement our own way to allocate the largest available
> >> area instead of using the feature from memzone: if an allocation fails,
> >> try to divide the size by 2 and retry. When the requested size falls
> >> below min_chunk_size, stop and return an error.
> >>
> >> Fixes: eba11e364614 ("mempool: reduce wasted space on populate")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> >
> > Sorry I forgot to report Anatoly's ack on v1
> > http://patchwork.dpdk.org/patch/64370/
> >
> > Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
>
> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
Applied, thanks
next prev parent reply other threads:[~2020-01-20 10:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-09 13:27 [dpdk-dev] [PATCH] mempool: fix slow allocation of large mempools Olivier Matz
2020-01-09 13:57 ` Burakov, Anatoly
2020-01-09 16:06 ` Ali Alnubani
2020-01-09 17:27 ` Olivier Matz
2020-01-10 9:53 ` Andrew Rybchenko
2020-01-17 8:45 ` Olivier Matz
2020-01-17 9:51 ` [dpdk-dev] [PATCH v2] " Olivier Matz
2020-01-17 10:01 ` Olivier Matz
2020-01-17 10:09 ` Andrew Rybchenko
2020-01-20 10:12 ` Thomas Monjalon [this message]
2020-01-19 12:29 ` Ali Alnubani
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=1863691.ZhSLo9btvA@xps \
--to=thomas@monjalon.net \
--cc=alialnu@mellanox.com \
--cc=anatoly.burakov@intel.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=olivier.matz@6wind.com \
--cc=rasland@mellanox.com \
--cc=stable@dpdk.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 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.