From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Marchand Subject: Re: [PATCH v4] eal: make hugetlb initialization more robust Date: Tue, 17 May 2016 18:39:03 +0200 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 Cc: "dev@dpdk.org" , Sergio Gonzalez Monroy , Neil Horman To: Jianfeng Tan Return-path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 205532BC3 for ; Tue, 17 May 2016 18:39:23 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id g17so40878681wme.1 for ; Tue, 17 May 2016 09:39:23 -0700 (PDT) In-Reply-To: <1463013881-27985-1-git-send-email-jianfeng.tan@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" 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. 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 ? > 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)); > + munmap(virtaddr, hugepage_sz); > + close(fd); > + unlink(hugepg_tbl[i].filepath); > + return i; > + } > + *(int *)virtaddr = 0; > + } > + > + > /* set shared flock on the file. */ > if (flock(fd, LOCK_SH | LOCK_NB) == -1) { > - RTE_LOG(ERR, EAL, "%s(): Locking file failed:%s \n", > + RTE_LOG(DEBUG, EAL, "%s(): Locking file failed:%s \n", > __func__, strerror(errno)); > close(fd); > - return -1; > + return i; > } > > close(fd); Maybe I missed something, but we are writing into some hugepage before the flock has been called. Are we sure there is nobody else using this hugepage ? Especially, can't this cause trouble to a primary process running if we start the exact same primary process ? -- David Marchand