From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
To: "shesha Sreenivasamurthy (shesha)" <shesha@cisco.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3] mem: command line option to delete hugepage backing files
Date: Thu, 22 Oct 2015 09:51:28 +0100 [thread overview]
Message-ID: <5628A390.9080602@intel.com> (raw)
In-Reply-To: <20151021163422.GA10344@bricha3-MOBL3>
On 21/10/2015 17:34, Bruce Richardson wrote:
> On Wed, Oct 21, 2015 at 04:22:45PM +0000, shesha Sreenivasamurthy (shesha) wrote:
>> When an application using huge-pages crash or exists, the hugetlbfs
>> backing files are not cleaned up. This is a patch to clean those files.
>> There are multi-process DPDK applications that may be benefited by those
>> backing files. Therefore, I have made that configurable so that the
>> application that does not need those backing files can remove them, thus
>> not changing the current default behavior. The application itself can
>> clean it up, however the rationale behind DPDK cleaning it up is, DPDK
>> created it and therefore, it is better it unlinks it.
>>
>> Signed-off-by: Shesha Sreenivasamurthy <shesha@cisco.com>
>> ---
>> lib/librte_eal/common/eal_common_options.c | 12 ++++++++++++
>> lib/librte_eal/common/eal_internal_cfg.h | 1 +
>> lib/librte_eal/common/eal_options.h | 2 ++
>> lib/librte_eal/linuxapp/eal/eal_memory.c | 30
>> ++++++++++++++++++++++++++++++
>> 4 files changed, 45 insertions(+)
>>
> <snip>
>> +static int
>> +unlink_hugepage_files(struct hugepage_file *hugepg_tbl,
>> + unsigned num_hp_info)
>> +{
>> + unsigned socket, size;
>> + int page, nrpages = 0;
>> +
>> + /* get total number of hugepages */
>> + for (size = 0; size < num_hp_info; size++)
>> + for (socket = 0; socket < RTE_MAX_NUMA_NODES; socket++)
>> + nrpages += internal_config.hugepage_info[size].num_pages[socket];
>> +
>> + for (page = 0; page < nrpages; page++) {
>> + struct hugepage_file *hp = &hugepg_tbl[page];
>> + if (hp->final_va != NULL && unlink(hp->filepath)) {
>> + RTE_LOG(WARNING, EAL, "%s(): Removing %s failed: %s\n",
>> + __func__, hp->filepath, strerror(errno));
>> + }
>> + }
>> + return 0;
>> +}
>> +
>> /*
>> * unmaps hugepages that are not going to be used. since we originally
>> allocate
>> * ALL hugepages (not just those we need), additional unmapping needs to
>> be done.
>> @@ -1289,6 +1311,14 @@ rte_eal_hugepage_init(void)
>> goto fail;
>> }
>>
>> + /* free the hugepage backing files */
>> + if (internal_config.hugepage_unlink &&
>> + unlink_hugepage_files(tmp_hp,
>> + internal_config.num_hugepage_sizes) < 0) {
>> + RTE_LOG(ERR, EAL, "Unlinking hugepage backing files failed!\n");
>> + goto fail;
>> + }
>> +
> Sorry for the late comment, but...
>
> Rather than adding a whole new function to be called here, can the same effect
> not be got by adding in 2/3 lines like:
> if (internal_config.hugepage_unlink)
> unlink(hugetlb[i].filepath)
>
> at line 409 of eal_memory.c where were have done our final mmap of the file.
> [You also need the same couple of lines for the 32-bit special case at line 351].
> It would be a shorter diff.
>
> /Bruce
If you wanted to avoid the extra function call, I might be cleaner to
just unlink all files when
doing unmap_all_hugepages_orig.
My two cents: I think it would be easier to read/debug having a function
that "unlinks files" instead
of unlinking files at different points in map_all_hugepages.
Unfortunately the proposed approach does not work for all cases:
- If we have single file segment, map_all_hugepages does not get call a
second time, instead we call
remap_all_hugepages
- If we use options -m or --socket-mem, because unmap_unneeded_hugepages
does not expect files
already unlinked, it will fail when trying to unlink unneeded
hugepage files.
The current patch would work as we only unlink after
unmap_unneeded_hugepages.
Sergio
next prev parent reply other threads:[~2015-10-22 8:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1445419101-19690-1-git-send-email-shesha@cisco.com>
2015-10-21 16:22 ` shesha Sreenivasamurthy (shesha)
2015-10-21 16:34 ` Bruce Richardson
2015-10-22 8:51 ` Sergio Gonzalez Monroy [this message]
2015-10-22 15:26 ` Bruce Richardson
2015-10-22 16:03 ` shesha Sreenivasamurthy (shesha)
2015-10-23 9:57 ` Sergio Gonzalez Monroy
2015-10-23 17:50 ` shesha Sreenivasamurthy (shesha)
2015-10-27 11:42 ` Sergio Gonzalez Monroy
2015-10-27 12:01 ` Sergio Gonzalez Monroy
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=5628A390.9080602@intel.com \
--to=sergio.gonzalez.monroy@intel.com \
--cc=dev@dpdk.org \
--cc=shesha@cisco.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).