From: Dmitry Kozlyuk <dkozlyuk@oss.nvidia.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>, Slava Ovsiienko <viacheslavo@oss.nvidia.com>,
"Anatoly Burakov" <anatoly.burakov@intel.com>
Subject: Re: [dpdk-dev] [PATCH v6 2/3] eal: add memory pre-allocation from existing files
Date: Tue, 12 Oct 2021 15:55:11 +0000 [thread overview]
Message-ID: <CH0PR12MB5091B6DF5DCC7A8F15D507EBB9B69@CH0PR12MB5091.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CAJFAV8yYKUwO+fXNWSpHFtsrVRN0DxdtGKR3y-onFKoAwdUxFA@mail.gmail.com>
Hello David,
> I have some trouble figuring the need for the list of files.
> Why not use a global knob --mem-clear-on-alloc for this behavior change?
Moving memset() doesn't speed anything up, it's a forced step for the reasons below.
Currently, memory is cleared by the kernel when a page is mapped during an allocation.
This cannot be turned off in stock kernels. The issue is that initial allocations are longer
by the time needed to clear the pages, which is >90%. For the memory intended for DMA this time is just wasted. If allocations are large, application startup and restart take long. The only way to get hugepages mapped without the kernel clearing them is to map existing files in hugetlbfs. However, rte_zmalloc() needs to return clean memory, that's why we move memset() there. Memory intended for DMA is just never cleared this way. But memory freed and allocated again will be cleared again, unfortunately.
next prev parent reply other threads:[~2021-10-12 15:55 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-05 12:49 [dpdk-dev] [PATCH 21.11 0/3] " Dmitry Kozlyuk
2021-07-05 12:49 ` [dpdk-dev] [PATCH 21.11 1/3] eal/linux: make hugetlbfs analysis reusable Dmitry Kozlyuk
2021-07-05 12:49 ` [dpdk-dev] [PATCH 21.11 2/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-07-05 12:49 ` [dpdk-dev] [PATCH 21.11 3/3] app/test: add allocator performance autotest Dmitry Kozlyuk
2021-07-16 11:08 ` [dpdk-dev] [PATCH 21.11 v2 0/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-07-16 11:08 ` [dpdk-dev] [PATCH 21.11 v2 1/3] eal/linux: make hugetlbfs analysis reusable Dmitry Kozlyuk
2021-07-16 11:08 ` [dpdk-dev] [PATCH 21.11 v2 2/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-07-16 11:08 ` [dpdk-dev] [PATCH 21.11 v2 3/3] app/test: add allocator performance autotest Dmitry Kozlyuk
2021-08-09 9:45 ` [dpdk-dev] [PATCH 21.11 v2 0/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-08-30 8:21 ` Dmitry Kozlyuk
2021-09-14 10:34 ` [dpdk-dev] [PATCH v3 " Dmitry Kozlyuk
2021-09-14 10:34 ` [dpdk-dev] [PATCH v3 1/3] eal/linux: make hugetlbfs analysis reusable Dmitry Kozlyuk
2021-09-14 12:48 ` John Levon
2021-09-14 12:57 ` Dmitry Kozlyuk
2021-09-16 12:08 ` John Levon
2021-09-14 10:34 ` [dpdk-dev] [PATCH v3 2/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-09-14 10:34 ` [dpdk-dev] [PATCH v3 3/3] app/test: add allocator performance autotest Dmitry Kozlyuk
2021-09-20 12:52 ` [dpdk-dev] [PATCH v4 0/3] eal: add memory pre-allocation from existing files dkozlyuk
2021-09-20 12:53 ` [dpdk-dev] [PATCH v4 1/3] eal/linux: make hugetlbfs analysis reusable dkozlyuk
2021-09-20 12:53 ` [dpdk-dev] [PATCH v4 2/3] eal: add memory pre-allocation from existing files dkozlyuk
2021-09-20 12:53 ` [dpdk-dev] [PATCH v4 3/3] app/test: add allocator performance autotest dkozlyuk
2021-09-21 8:16 ` [dpdk-dev] [PATCH v5 0/3] eal: add memory pre-allocation from existing files dkozlyuk
2021-09-21 8:16 ` [dpdk-dev] [PATCH v5 1/3] eal/linux: make hugetlbfs analysis reusable dkozlyuk
2021-09-22 13:52 ` John Levon
2021-10-05 17:36 ` Thomas Monjalon
2021-10-08 15:33 ` John Levon
2021-10-08 15:50 ` Dmitry Kozlyuk
2021-09-21 8:16 ` [dpdk-dev] [PATCH v5 2/3] eal: add memory pre-allocation from existing files dkozlyuk
2021-09-21 8:16 ` [dpdk-dev] [PATCH v5 3/3] app/test: add allocator performance autotest dkozlyuk
2021-10-11 8:56 ` [dpdk-dev] [PATCH v6 0/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-10-11 8:56 ` [dpdk-dev] [PATCH v6 1/3] eal/linux: make hugetlbfs analysis reusable Dmitry Kozlyuk
2021-10-13 8:16 ` David Marchand
2021-10-13 9:21 ` Dmitry Kozlyuk
2021-10-11 8:56 ` [dpdk-dev] [PATCH v6 2/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-10-12 15:37 ` David Marchand
2021-10-12 15:55 ` Dmitry Kozlyuk [this message]
2021-10-12 17:32 ` David Marchand
2021-10-12 21:09 ` Dmitry Kozlyuk
2021-10-13 10:18 ` David Marchand
2021-11-08 14:27 ` Dmitry Kozlyuk
2021-11-08 17:45 ` David Marchand
2021-10-11 8:56 ` [dpdk-dev] [PATCH v6 3/3] app/test: add allocator performance autotest Dmitry Kozlyuk
2021-10-12 13:53 ` Aaron Conole
2021-10-12 14:48 ` Dmitry Kozlyuk
2021-10-15 13:47 ` Aaron Conole
2021-10-11 18:52 ` [dpdk-dev] [PATCH v6 0/3] eal: add memory pre-allocation from existing files Thomas Monjalon
2021-10-11 21:12 ` [dpdk-dev] [dpdk-ci] " Lincoln Lavoie
2021-10-12 6:54 ` Thomas Monjalon
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=CH0PR12MB5091B6DF5DCC7A8F15D507EBB9B69@CH0PR12MB5091.namprd12.prod.outlook.com \
--to=dkozlyuk@oss.nvidia.com \
--cc=anatoly.burakov@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=viacheslavo@oss.nvidia.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).