From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 38A53A00C3; Mon, 17 Jan 2022 15:24:06 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B3EF0411FE; Mon, 17 Jan 2022 15:24:05 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 30BFC40141 for ; Mon, 17 Jan 2022 15:24:04 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id CDD865C0788; Mon, 17 Jan 2022 09:24:02 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 17 Jan 2022 09:24:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= WX4arPuuCwZfaoY6aa1xSOs64IM/rHkSTmugsE5cKoQ=; b=OUSgSKy4M38nDa1T 7+AM08l+4ugAP4kI8/Z/h0ZlQ+lkhf0QIsRBWK9ON08J33XPaK/Vzk+OotKipiUA ZDkcoYrXaZoiFQ0B4cvTLQ3xhXbhkXOFlE1u3DHhyItR9SXXnz/DnqQ+Cq9OtpoK qmfNDjmGQycCRFCyq3brnPPbGofYYIQrAg4YREUyo6Ebl5AmLLGstOgajSSPIa+1 6C2RAqycVmV+VbJ+z9ZWSQ/Yos24M2QE0p+8rt0ZKbhqmp3Oe0XUYFv5Hr6L+qt3 f2BfjR6zceuC/LYNV+f1hiXswtWi4+vWuaDWPwd5gVBRdoFwX1xkdaF5tWx0N4Hj 3/FObg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=WX4arPuuCwZfaoY6aa1xSOs64IM/rHkSTmugsE5cK oQ=; b=RTbjN5mVVcaSWT/dhfOFxx/U8VqhajntkQTYY5WZedP5Dj2K+FSHMmRsC ZbQLoZqVQDJmwDrdfSGE8w+DVg7papBw4h2/R5o66GLTe8i86pOR8G9e5cFfidoA 59Ob0M6mCaQQQTtqCCoysdqc3ytbjj6vNy4b8eg7jcFaRd1QGDVzvWCNcFafn13o VSGqAnCXxoS6g+pEO724/eVhEV2H4mgxeovUchvD2KKCbERqYfH5hzIk/AZlMhmc vOvjS32SxApKCjV03tfYhtKz9kUwofQ26jzsJx5YqRshAuXcPZ6LLJl279AH3UcH V/lXHq6kUEtZxlj3SHDqOVs6YcAYg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddugdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Jan 2022 09:24:01 -0500 (EST) From: Thomas Monjalon To: Dmitry Kozlyuk Cc: dev@dpdk.org, Anatoly Burakov Subject: Re: [PATCH v1 5/6] eal/linux: allow hugepage file reuse Date: Mon, 17 Jan 2022 15:24:00 +0100 Message-ID: <2524947.9Mp67QZiUf@thomas> In-Reply-To: <20220117081406.482210-1-dkozlyuk@nvidia.com> References: <20220117080801.481568-1-dkozlyuk@nvidia.com> <20220117081406.482210-1-dkozlyuk@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 17/01/2022 09:14, Dmitry Kozlyuk: > Linux EAL ensured that mapped hugepages are clean > by always mapping from newly created files: > existing hugepage backing files were always removed. > In this case, the kernel clears the page to prevent data leaks, > because the mapped memory may contain leftover data > from the previous process that was using this memory. > Clearing takes the bulk of the time spent in mmap(2), > increasing EAL initialization time. > > Introduce a mode to keep existing files and reuse them > in order to speed up initial memory allocation in EAL. > Hugepages mapped from such files may contain data > left by the previous process that used this memory, > so RTE_MEMSEG_FLAG_DIRTY is set for their segments. > If multiple hugepages are mapped from the same file: > 1. When fallocate(2) is used, all memory mapped from this file > is considered dirty, because it is unknown > which parts of the file are holes. > 2. When ftruncate(3) is used, memory mapped from this file > is considered dirty unless the file is extended > to create a new mapping, which implies clean memory. [...] > struct hugepage_file_discipline { > /** Unlink files before mapping them to leave no trace in hugetlbfs. */ > bool unlink_before_mapping; > + /** Reuse existing files, never delete or re-create them. */ > + bool keep_existing; > }; That's a bit confusing to mix "unlink" and "keep". I would prefer focusing on what is done, i.e. unlink when. I like "unlink_before_mapping" because it is a real action. The other action should be "unlink_existing" or "unlink_before_creating".