From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Marchand Subject: Re: [PATCH v4] eal: make hugetlb initialization more robust Date: Wed, 18 May 2016 11:38:18 +0200 Message-ID: References: <1457089092-4128-1-git-send-email-jianfeng.tan@intel.com> <1463013881-27985-1-git-send-email-jianfeng.tan@intel.com> <1671292.hQI6ccxuUZ@xps13> <63ae23d7-7ca3-46e5-cfc1-1a6684395428@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Thomas Monjalon , Jianfeng Tan , "dev@dpdk.org" , Neil Horman To: Sergio Gonzalez Monroy Return-path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id C3A685A90 for ; Wed, 18 May 2016 11:38:38 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id a17so70074020wme.0 for ; Wed, 18 May 2016 02:38:38 -0700 (PDT) In-Reply-To: <63ae23d7-7ca3-46e5-cfc1-1a6684395428@intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, May 18, 2016 at 10:06 AM, Sergio Gonzalez Monroy wrote: > On 17/05/2016 17:40, Thomas Monjalon wrote: >> >> 2016-05-12 00:44, Jianfeng Tan: >>> >>> This patch adds an option, --huge-trybest, to use a recover mechanism to >>> the case that there are not so many hugepages (declared in sysfs), which >>> can be used. It relys on a mem access to fault-in hugepages, and if fails >> >> relys -> relies >> >>> with SIGBUS, recover to previously saved stack environment with >>> siglongjmp(). >>> >>> Besides, this solution fixes an issue when hugetlbfs is specified with an >>> option of size. Currently DPDK does not respect the quota of a hugetblfs >>> mount. It fails to init the EAL because it tries to map the number of >>> free >>> hugepages in the system rather than using the number specified in the >>> quota >>> for that mount. >> >> It looks to be a bug. Why adding an option? >> What is the benefit of the old behaviour, not using --try-best? > > > I do not see any benefit to the old behavior. > Given that we need the signal handling for the cgroup use case, I would be > inclined to use > this method as the default instead of trying to figure out how many > hugepages we have free, etc. +1 -- David Marchand