From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by dpdk.org (Postfix) with ESMTP id 30F3E595C for ; Tue, 29 Sep 2015 19:50:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4962; q=dns/txt; s=iport; t=1443549009; x=1444758609; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4owueoa9L77j8bZSQJM4H6rcggQPYB8gb3bvctoIK1Y=; b=dmL2SU6Eb2t3XUcRivLs991L4A/nGuX1MK9tfxU35blwV8hgd4IsfNju 5Zga3OFqYMhDWYP0StcWOOfWhmLkbvMo27SKjBpbrITEMM7hDr9xBPmPP aaSsGEfUBKR2BU6MJtGcGvtXtT9lq3wMAOwihWfudnYEzrg+T+EEwo3hi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DvAQCezgpW/4YNJK1egldNgT0GvWMBDYd0AoFSOBQBAQEBAQEBgQqEJAEBAQR5EAIBCBEDAQIoBzIUCQgCBA4FiC7MBQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLcIR8EQeELAWVdAGNEptEHwEBQoQBcYgZgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,609,1437436800"; d="scan'208,217";a="36500134" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 29 Sep 2015 17:50:03 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t8THo2DS029727 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Sep 2015 17:50:02 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 29 Sep 2015 12:50:01 -0500 Received: from xhc-aln-x13.cisco.com (173.36.12.87) by xch-aln-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 29 Sep 2015 12:50:01 -0500 Received: from xmb-aln-x03.cisco.com ([169.254.6.63]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0248.002; Tue, 29 Sep 2015 12:50:01 -0500 From: "shesha Sreenivasamurthy (shesha)" To: "Michael S. Tsirkin" Thread-Topic: [dpdk-dev] Unlinking hugepage backing file after initialiation Thread-Index: AQHQ+kpckJG1vBipX0G0rq8U7ayRsJ5ThlyAgAB9RAD//6TIgA== Date: Tue, 29 Sep 2015 17:50:00 +0000 Message-ID: References: <20150929161628.GA3810@redhat.com> In-Reply-To: <20150929161628.GA3810@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.30] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 17:50:09 -0000 Sure. Then, is there any real reason why the backing files should not be un= linked ? -- - Thanks char * (*shesha) (uint64_t cache, uint8_t F00D) { return 0x0000C0DE; } From: "Michael S. Tsirkin" > Date: Tuesday, September 29, 2015 at 9:16 AM To: Cisco Employee > Cc: "Xie, Huawei" >, "dev= @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 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 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 mem= ory 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