From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8313; q=dns/txt; s=iport; t=1443541691; x=1444751291; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=d60yg4TJbQA9y5g5oTu/KLE6Eab+KOYRijkieDjzk7g=; b=jOIVtUYDhIpAHZb7Ymss0eU5NlXlyk6mdxcIBsmYk4ve6Nr+BxXnXHCu MsiF8x6/fKxjF9UKY8VMCgk5DaCVZUhiOZ5dZe0bDG2AfzeYyzU7DRAYp gkaooWnfdjrFcY8r8Ppa/p8Kda0g5JaEiOqcEOlLRs6oAfTPg+KdDthsF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJAgBNsgpW/40NJK1dgldNgT0GvWMBDYd0AoFQOBQBAQEBAQEBgQqEJAEBAQR5EAIBCBEDAQIoBzIUCQgCBA4FG4gTy3EBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi3CEfBEHhCwFkkSDMAGNEptEHwEBQoQBcYdXJB+BBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,608,1437436800"; d="scan'208,217";a="191783422" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 29 Sep 2015 15:48:09 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t8TFm9Cg007245 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Sep 2015 15:48:09 GMT Received: from xch-aln-012.cisco.com (173.36.7.22) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 29 Sep 2015 10:48:09 -0500 Received: from xhc-aln-x04.cisco.com (173.36.12.78) by xch-aln-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 29 Sep 2015 10:48:09 -0500 Received: from xmb-aln-x03.cisco.com ([169.254.6.63]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0248.002; Tue, 29 Sep 2015 10:48:08 -0500 From: "shesha Sreenivasamurthy (shesha)" To: "Xie, Huawei" Thread-Topic: [dpdk-dev] Unlinking hugepage backing file after initialiation Thread-Index: AQHQ+kpckJG1vBipX0G0rq8U7ayRsJ5ThlyA Date: Tue, 29 Sep 2015 15:48:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.13] 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" , "ms >> Michael S. Tsirkin" 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 15:48:11 -0000 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; }