From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 7A62066DB for ; Thu, 19 May 2016 04:00:40 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP; 18 May 2016 19:00:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,332,1459839600"; d="scan'208";a="106554552" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.193]) ([10.239.67.193]) by fmsmga004.fm.intel.com with ESMTP; 18 May 2016 19:00:36 -0700 To: David Marchand References: <1457089092-4128-1-git-send-email-jianfeng.tan@intel.com> <1463013881-27985-1-git-send-email-jianfeng.tan@intel.com> Cc: "dev@dpdk.org" , Sergio Gonzalez Monroy , Neil Horman From: "Tan, Jianfeng" Message-ID: Date: Thu, 19 May 2016 10:00:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4] eal: make hugetlb initialization more robust 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: Thu, 19 May 2016 02:00:40 -0000 Hi David, On 5/18/2016 12:39 AM, David Marchand wrote: > Hello Jianfeng, > > On Thu, May 12, 2016 at 2:44 AM, Jianfeng Tan wrote: >> 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 >> 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's still an open issue with CONFIG_RTE_EAL_SINGLE_FILE_SEGMENTS. Under >> this case (such as IVSHMEM target), having hugetlbfs mounts with quota will >> fail to remap hugepages as it relies on having mapped all free hugepages >> in the system. > > > >> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c >> index 5b9132c..8c77010 100644 >> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c >> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c >> @@ -417,12 +434,33 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl, >> hugepg_tbl[i].final_va = virtaddr; >> } >> >> + if (orig && internal_config.huge_trybest) { >> + /* In linux, hugetlb limitations, like cgroup, are >> + * enforced at fault time instead of mmap(), even >> + * with the option of MAP_POPULATE. Kernel will send >> + * a SIGBUS signal. To avoid to be killed, save stack >> + * environment here, if SIGBUS happens, we can jump >> + * back here. >> + */ >> + if (wrap_sigsetjmp()) { >> + RTE_LOG(DEBUG, EAL, "SIGBUS: Cannot mmap more " >> + "hugepages of size %u MB\n", >> + (unsigned)(hugepage_sz / 0x100000)); > For such a case case, maybe having some warning log message when it > fails would help the user. > + a known issue in the release notes ? Do you mean when sigbus is triggered, like here, warn the user that "it fails to hold all free hugepages as sysfs shows", and #ifdef RTE_EAL_SINGLE_FILE_SEGMENTS /*we need to return error from rte_eal_init_memory */ #endif Thanks, Jianfeng