DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "shesha Sreenivasamurthy (shesha)" <shesha@cisco.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v3] mem: command line option to delete hugepage backing files
Date: Wed, 21 Oct 2015 17:34:22 +0100	[thread overview]
Message-ID: <20151021163422.GA10344@bricha3-MOBL3> (raw)
In-Reply-To: <D24D0953.23D9B%shesha@cisco.com>

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

  reply	other threads:[~2015-10-21 16:34 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 [this message]
2015-10-22  8:51     ` Sergio Gonzalez Monroy
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=20151021163422.GA10344@bricha3-MOBL3 \
    --to=bruce.richardson@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).