[dpdk-dev] Unlinking hugepage backing file after initialiation

shesha Sreenivasamurthy (shesha) shesha at cisco.com
Tue Sep 29 19:50:00 CEST 2015


Sure. Then, is there any real reason why the backing files should not be unlinked ?

--
- Thanks
char * (*shesha) (uint64_t cache, uint8_t F00D)
{ return 0x0000C0DE; }

From: "Michael S. Tsirkin" <mst at redhat.com<mailto:mst at redhat.com>>
Date: Tuesday, September 29, 2015 at 9:16 AM
To: Cisco Employee <shesha at cisco.com<mailto:shesha at cisco.com>>
Cc: "Xie, Huawei" <huawei.xie at intel.com<mailto:huawei.xie at intel.com>>, "dev at dpdk.org<mailto:dev at dpdk.org>" <dev at dpdk.org<mailto:dev at dpdk.org>>
Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation

On Tue, Sep 29, 2015 at 03:48:08PM +0000, shesha Sreenivasamurthy (shesha) wrote:
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.

guest memory is allocated an freed by hypervisor, right?
I don't think it's dpdk's job.

--
MST



More information about the dev mailing list