From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tan, Jianfeng" Subject: Re: [PATCH v4] eal: make hugetlb initialization more robust Date: Thu, 19 May 2016 10:00:35 +0800 Message-ID: References: <1457089092-4128-1-git-send-email-jianfeng.tan@intel.com> <1463013881-27985-1-git-send-email-jianfeng.tan@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" , Sergio Gonzalez Monroy , Neil Horman To: David Marchand 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) In-Reply-To: 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" 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