From mboxrd@z Thu Jan 1 00:00:00 1970 From: "shesha Sreenivasamurthy (shesha)" Subject: Unlinking hugepage backing file after initialiation Date: Tue, 29 Sep 2015 00:04:07 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: "dev@dpdk.org" Return-path: Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by dpdk.org (Postfix) with ESMTP id 149BC1396 for ; Tue, 29 Sep 2015 02:04:09 +0200 (CEST) Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t8T048k6024384 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Sep 2015 00:04:08 GMT Content-Language: en-US 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" Hello, As of DPDK2.1, backing files are created in hugetablefs during mapping (in = eal_memory.c::rte_eal_hugepage_init()) and these files are not cleaned up (= unlinked) after initialization (mmap-ing). This means, when the application= crashes or stopped, the memory is still consumed. Therefore, is there any = reason not to unlink backing files after initialization ? If no, I will sen= d a patch for the change. -- - Thanks char * (*shesha) (uint64_t cache, uint8_t F00D) { return 0x0000C0DE; }