From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergio Gonzalez Monroy Subject: Re: [PATCH v8] mem: command line option to delete hugepage backing files Date: Wed, 28 Oct 2015 23:23:59 +0000 Message-ID: <5631590F.9040606@intel.com> References: <1446069865-18733-1-git-send-email-shesha@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Shesha Sreenivasamurthy Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 797875682 for ; Thu, 29 Oct 2015 00:24:12 +0100 (CET) In-Reply-To: <1446069865-18733-1-git-send-email-shesha@cisco.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 28/10/2015 22:04, Shesha Sreenivasamurthy 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 > Acked-by: Sergio Gonzalez Monroy > --- v3: - Fix typo in comments v2: - Update function X return value > 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 | 32 ++++++++++++++++++++++++++++++ > 4 files changed, 47 insertions(+) > > Patch looks good! Just a couple of things for the next time ;) You might be aware of them, but it doesn't hurt to remind them: - When sending new version, use --in-reply-to to the last version of the patch sent, it's easier to have all patches on the same thread (if your email client supports it) - Also when sending new versions it's useful to add what has changed from the previous to the new version. (add such info after the three dashes as shown above) Cheers, Sergio