From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 6F60CA0679 for ; Tue, 2 Apr 2019 16:08:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A307034F3; Tue, 2 Apr 2019 16:08:29 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id B74AA343C for ; Tue, 2 Apr 2019 16:08:28 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F070820E6B; Tue, 2 Apr 2019 10:08:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 02 Apr 2019 10:08:28 -0400 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=mesmtp; bh=8IN9Ygy18UmTJ5HmRbcZhPoxORjbHHqu+0eBpkjDyVc=; b=kwuU0gnwEX/X nVHwatfZNfv4Hm3RgMGUkyhKsOuGko1gtfHBb0G/eBDlfllxHYKgO6jYy9qLX5i1 YxjViQNu+N/UdDECAfxxZ0YYI6Qxgn0SpAHXf67zMGjEIiq2LpR7YCdUolRbEDDv 8i7AtFtCwtn7QlwQiAFKKK0/JLDDBb8= 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=fm2; bh=8IN9Ygy18UmTJ5HmRbcZhPoxORjbHHqu+0eBpkjDy Vc=; b=pgz5pQv++g01vWaj/EMY2vhqNIinzsxlfplCxTfojtvo1FReUj7Xtk8BC UaS6+yEg2sIwqwvXwddZDLeyjtTMZKhHF1AYN3rV2TkeBUaBU02z7+h3QPfyQz2/ TemqZ4RHwgqGDnB4qWSY9zEwaOiLCpIePvks8/zUfJ4VtcZ2kNYa58vAfZgxqTmG wUH8tefGEa61IZPtWic891UAKSTg4dtkLf2piM4TzVoJmeC3UTa9RT+EJBSbfv5l TafYQgbuMEAMrGc9h/wkW7ITXZh6Rk+GgRc8VwwThj4kRrj7193yymgmgr+s9cYJ ctDDSujoO7DZJfi5S7/WL+tCU0LdQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtddtgdehvdculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvden ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg hlohhnrdhnvghtqeenucffohhmrghinhepughpughkrdhorhhgnecukfhppeejjedrudef gedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmoh hnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3A1D810391; Tue, 2 Apr 2019 10:08:26 -0400 (EDT) From: Thomas Monjalon To: Anatoly Burakov Cc: dev@dpdk.org, John McNamara , Marko Kovacevic , david.marchand@redhat.com, maxime.coquelin@redhat.com Date: Tue, 02 Apr 2019 16:08:24 +0200 Message-ID: <4936199.LOJ53TdX45@xps> In-Reply-To: <2b5404285e5ddc460a857cc90130db1b2c717dfc.1553882085.git.anatoly.burakov@intel.com> References: <728c19fa1ed26cdd319fe65e23c4058363dbf2dd.1553882085.git.anatoly.burakov@intel.com> <2b5404285e5ddc460a857cc90130db1b2c717dfc.1553882085.git.anatoly.burakov@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 2/2] memalloc: do not use lockfiles for single file segments mode X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190402140824.eMK7EBQfcS2MGxZFyVk-1lkWniS-NxcXWrczaoU7Saw@z> 29/03/2019 18:55, Anatoly Burakov: > Due to internal glibc limitations [1], DPDK may exhaust internal > file descriptor limits when using smaller page sizes, which results > in inability to use system calls such as select() by user > applications. > > Single file segments option stores lock files per page to ensure > that pages are deleted when there are no more users, however this > is not necessary because the processes will be holding onto the > pages anyway because of mmap(). Thus, removing pages from the > filesystem is safe even though they may be used by some other > secondary process. As a result, single file segments mode no > longer stores inordinate amounts of segment fd's, and the above > issue with fd limits is solved. > > However, this will not work for legacy mem mode. For that, simply > document that using bigger page sizes is the only option. > > [1] https://mails.dpdk.org/archives/dev/2019-February/124386.html > > Signed-off-by: Anatoly Burakov Applied, thanks