From mboxrd@z Thu Jan 1 00:00:00 1970 From: "shesha Sreenivasamurthy (shesha)" Subject: Re: Unlinking hugepage backing file after initialiation Date: Tue, 29 Sep 2015 15:48:08 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "ms >> Michael S. Tsirkin" To: "Xie, Huawei" Return-path: Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by dpdk.org (Postfix) with ESMTP id 22B0EB62 for ; Tue, 29 Sep 2015 17:48:11 +0200 (CEST) In-Reply-To: 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" If huge pages are allocated for the guest and if the guest crashes there ma= y be a chance that the new guest may not be able to get huge pages again as= some other guest or process on the host used it. But I am not able to unde= rstand memory corruption you are talking about. In my opinion, if a process= using a piece of memory goes away, it should not re-attach to the same pie= ce of memory without running a sanity check on it. -- - Thanks char * (*shesha) (uint64_t cache, uint8_t F00D) { return 0x0000C0DE; } From: "Xie, Huawei" > Date: Tuesday, September 29, 2015 at 8:15 AM To: Cisco Employee > Cc: "dev@dpdk.org" >= , "ms >> Michael S. Tsirkin" > Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation On 9/29/2015 10:38 AM, Xie, Huawei wrote: On 9/29/2015 8:04 AM, shesha Sreenivasamurthy (shesha) wrote: 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. shesha: You remind me the virtio unexpected crashing issue. DPDK runs in user space. It is quite possible it dies unexpectedly, either crash or being killed. When the dpdk virtio app crashes, it doesn't have a chance to notify host, so host is still using its memory, backed by guest huge page. If huge page files are still reserved in hugetlbfs, we have a chance to recover virtio first, then unlink the huge pages. Otherwise if the huge pages are allocated by other process, its memory could be corrupted by host. Certainly it is not implemented like that for this purpose, but i think it is a temporary solution for this user space virtio driver issue. I realized it is not a virtio specific issue, but apply to all user space driver. And the chance is very very small. Also commented by Bruce/Konstantin, it is implemented this way for multiple processes. /huawei -- - Thanks char * (*shesha) (uint64_t cache, uint8_t F00D) { return 0x0000C0DE; }