From: 王志克 <wangzhike@jd.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
"zhihong.wang@intel.com" <zhihong.wang@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-dev] long initialization of rte_eal_hugepage_init
Date: Wed, 6 Sep 2017 06:45:05 +0000 [thread overview]
Message-ID: <6DAF063A35010343823807B082E5681F1A72FE2E@mbx05.360buyAD.local> (raw)
In-Reply-To: <CAOaVG15NhZXhPCR5VDS-O+FVpx1muAY7z2HMTHT-smDpZadK9A@mail.gmail.com>
Hi Stephen,
Do you means “disable zero huge page” would improve the performance? How can the memory be guarantee<http://www.baidu.com/link?url=OcSiFdTLN-XzcXbWcNS7WKEDAs5KPRf5SoQeihstSK0eIPPoRsFICa7XLymTk-ln_XJ5mXmGU9C4srI6Nwax6IgorIeptfF9NvgooO1z4B3>d to be allocated? Would it introduce function issue?
I checked below commit, and I guess the commit at least means the “zero the huge page” is needed.
commit 5ce3ace1de458e2ded1b408acfe59c15cf9863f1
Author: Zhihong Wang <zhihong.wang@intel.com>
Date: Sun Nov 22 14:13:35 2015 -0500
eal: remove unnecessary hugepage zero-filling
The kernel fills new allocated (huge) pages with zeros.
DPDK just has to populate page tables to trigger the allocation.
Signed-off-by: Zhihong Wang <zhihong.wang@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
From: Stephen Hemminger [mailto:stephen@networkplumber.org]
Sent: Wednesday, September 06, 2017 12:24 PM
To: 王志克
Cc: dev@dpdk.org; users@dpdk.org
Subject: Re: [dpdk-dev] long initialization of rte_eal_hugepage_init
Linux zeros huge pages by default. There was a fix in later releases
On Sep 5, 2017 8:24 PM, "王志克" <wangzhike@jd.com<mailto:wangzhike@jd.com>> wrote:
Hi All,
I observed that rte_eal_hugepage_init() will take quite long time if there are lots of huge pages. Example I have 500 1G huge pages, and it takes about 2 minutes. That is too long especially for application restart case.
If the application only needs limited huge page while the host have lots of huge pages, the algorithm is not so efficent. Example, we only need 1G memory from each socket.
What is the proposal from DPDK community? Any solution?
Note I tried version dpdk 16.11.
Br,
Wang Zhike
next prev parent reply other threads:[~2017-09-06 6:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-06 3:24 王志克
2017-09-06 4:24 ` Stephen Hemminger
2017-09-06 6:45 ` 王志克 [this message]
2017-09-06 4:35 ` Pavan Nikhilesh Bhagavatula
2017-09-06 7:37 ` Sergio Gonzalez Monroy
2017-09-06 8:59 ` 王志克
2017-09-06 4:36 ` Tan, Jianfeng
2017-09-06 6:02 ` 王志克
2017-09-06 7:17 ` Tan, Jianfeng
2017-09-06 8:58 ` 王志克
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=6DAF063A35010343823807B082E5681F1A72FE2E@mbx05.360buyAD.local \
--to=wangzhike@jd.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
--cc=users@dpdk.org \
--cc=zhihong.wang@intel.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 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).