If huge pages are allocated for the guest and if the guest crashes there may 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 understand
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 piece of memory
without running a sanity check on it.
--
- Thanks
char * (*shesha) (uint64_t cache, uint8_t F00D)
{ return 0x0000C0DE; }
From: "Xie, Huawei" <huawei.xie at intel.com<mailto:huawei....@intel.com>>
Date: Tuesday, September 29, 2015 at 8:15 AM
To: Cisco Employee <shesha at cisco.com<mailto:shesha at cisco.com>>
Cc: "dev at dpdk.org<mailto:dev at dpdk.org>" <dev at dpdk.org<mailto:dev at
dpdk.org>>, "ms >> Michael S. Tsirkin" <mst at redhat.com<mailto:mst at
redhat.com>>
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 send 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; }
