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 5E601A00C3; Mon, 17 Jan 2022 15:27:30 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DD4A141203; Mon, 17 Jan 2022 15:27:29 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 5019640141 for ; Mon, 17 Jan 2022 15:27:28 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E0AD85C0D82; Mon, 17 Jan 2022 09:27:27 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 17 Jan 2022 09:27:27 -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= xvMn1bBbCwHJTzFdo8HrVWch1uVL9elRXBMZgczJKcU=; b=LDiT4CLcAWsp7y9V mcDjKoKNntwLwuV7J0ugZAl2bjVGKEUqcArIANvFQ6M4EfyGHW1RoErTCz5gmydI ay72wEQOydoO6FgMQ40vm6honX46N9nTIRkVY2AGS7SUFqMC9gIsj7EIVp/8L6nZ IxBp35xdHKyYv3RCAFAM3wXduNn2z2IsiPIoAaijbW/L+Hr9PBHCEvoNXHj6jlom 9sKUYj+Jio6Xs8PB90sKsRNtn1fX2QRpHDYjDHLVFeoqEqqSuaEaZ/XaixUUH9c6 5CFSyOOYs9UrsV+OqRXWHtI13sDJT21Dp892ToR0c1VJhtGOiioHau6lnhZeF14r LYx08Q== 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=xvMn1bBbCwHJTzFdo8HrVWch1uVL9elRXBMZgczJK cU=; b=gwWYB713FxomF6DdoIlOLkavColsJ7kHno3j1r74FbTfHKr+k70L/84UN QnFuNjD7cmSuYF4/OiW1s/qNACviezn9htiIBnWGl7uKGhq8LbaxfgzXD8AmLs7/ pNFoGN7NW5bJ8mzQhoGfOoaEwyRQXzn0cfX0Bh/Fe8S96S6m4R9Q2kfSLrgtaigt SH9TE3lJTrnq74u1fVAQc7tcqzV4XJPLP+5RzEJMxKr128tF4cpr9ewBMURt/MoR +PpfGyDirWRd6CnmI51zAwfVzuyS0s7e6aMNoaSOzcOyZjNl+5SsqpGZu99TlHtJ GZlQgp4NJI2GTMERRJL0CbrGUWxYg== 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:27:27 -0500 (EST) From: Thomas Monjalon To: Dmitry Kozlyuk Cc: dev@dpdk.org, Anatoly Burakov Subject: Re: [PATCH v1 6/6] eal: extend --huge-unlink for hugepage file reuse Date: Mon, 17 Jan 2022 15:27:26 +0100 Message-ID: <2604913.uZKlY2gecq@thomas> In-Reply-To: <20220117081440.482410-1-dkozlyuk@nvidia.com> References: <20220117080801.481568-1-dkozlyuk@nvidia.com> <20220117081440.482410-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: > Expose Linux EAL ability to reuse existing hugepage files > via --huge-unlink=never switch. > Default behavior is unchanged, it can also be specified > using --huge-unlink=existing for consistency. > Old --huge-unlink switch is kept, > it is an alias for --huge-unlink=always. > > Signed-off-by: Dmitry Kozlyuk > --- > doc/guides/linux_gsg/linux_eal_parameters.rst | 21 ++++++++-- > .../prog_guide/env_abstraction_layer.rst | 9 +++++ > doc/guides/rel_notes/release_22_03.rst | 7 ++++ > lib/eal/common/eal_common_options.c | 39 +++++++++++++++++-- > 4 files changed, 69 insertions(+), 7 deletions(-) > > diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst b/doc/guides/linux_gsg/linux_eal_parameters.rst > index 74df2611b5..7586f15ce3 100644 > --- a/doc/guides/linux_gsg/linux_eal_parameters.rst > +++ b/doc/guides/linux_gsg/linux_eal_parameters.rst > @@ -84,10 +84,23 @@ Memory-related options > Use specified hugetlbfs directory instead of autodetected ones. This can be > a sub-directory within a hugetlbfs mountpoint. > > -* ``--huge-unlink`` > - > - Unlink hugepage files after creating them (implies no secondary process > - support). > +* ``--huge-unlink[=existing|always|never]`` > + > + No ``--huge-unlink`` option or ``--huge-unlink=existing`` is the default: > + existing hugepage files are removed and re-created > + to ensure the kernel clears the memory and prevents any data leaks. > + > + With ``--huge-unlink`` (no value) or ``--huge-unlink=always``, > + hugepage files are also removed after creating them, > + so that the application leaves no files in hugetlbfs. > + This mode implies no multi-process support. > + > + When ``--huge-unlink=never`` is specified, existing hugepage files > + are not removed either before or after mapping them. One detail not clear: the second unlink is before or after mapping? > + This makes restart faster by saving time to clear memory at initialization, > + but it may slow down zeroed allocations later. > + Reused hugepages can contain data from previous processes that used them, > + which may be a security concern. I absolutely love these options. It keeps compability while making things consistent and understandable. Acked-by: Thomas Monjalon