From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilya Maximets Subject: Re: [PATCH v7 0/2] Balanced allocation of hugepages Date: Tue, 27 Jun 2017 11:42:36 +0300 Message-ID: References: <1498032250-24924-1-git-send-email-i.maximets@samsung.com> <1498039711-26570-1-git-send-email-i.maximets@samsung.com> <474367ef-6d51-652a-936e-1eb90fda0bd9@samsung.com> <1bd98f0a-2668-baee-1ee3-e1fc715b6841@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: David Marchand , Heetae Ahn , Yuanhan Liu , Jianfeng Tan , Neil Horman , Yulong Pei , Jerin Jacob To: Sergio Gonzalez Monroy , dev@dpdk.org, Thomas Monjalon , Bruce Richardson Return-path: Received: from mailout4.w1.samsung.com (mailout4.w1.samsung.com [210.118.77.14]) by dpdk.org (Postfix) with ESMTP id BF81F374 for ; Tue, 27 Jun 2017 10:42:41 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0OS70004N6V39470@mailout4.w1.samsung.com> for dev@dpdk.org; Tue, 27 Jun 2017 09:42:39 +0100 (BST) In-reply-to: <1bd98f0a-2668-baee-1ee3-e1fc715b6841@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 26.06.2017 18:33, Sergio Gonzalez Monroy wrote: > On 26/06/2017 11:44, Ilya Maximets wrote: >> So, what do you think about this version? >> Is it ready for merge or some additional changes needed? > > I was just having another look at it and was wondering if we should re-set the old policy instead of DEFAULT? Yes. I tried to do that previously, but it requires some manipulations get maximum nodemask size supported by kernel. So, I've implemented this behaviour with help of libnuma which makes a lot of checks while library initialisation (constructor). I'll send v8 with that soon. > Also noticed that we probably should increase essential_memory by hugepage_sz in > case of SIGBUS? I think there is an issue if we have more than one size. Good catch. Also fixed in v8. Additionally I found that we need to restore old mempolicy in case of any error. So I replaced all the 'return i' to the out to proper termination point. > > Thanks, > Sergio > >> Best regards, Ilya Maximets. >> >> On 21.06.2017 13:08, Ilya Maximets wrote: >>> Version 7: >>> * RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES >>> >>> Version 6: >>> * Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES >>> returned. Enabled by default for x86, ppc and thunderx. >>> >>> Version 5: >>> * Fixed shared build. (Automated build test will fail >>> anyway because libnuma-devel not installed on build servers) >>> >>> Version 4: >>> * Fixed work on systems without NUMA by adding check for NUMA >>> support in kernel. >>> >>> Version 3: >>> * Implemented hybrid schema for allocation. >>> * Fixed not needed mempolicy change while remapping. (orig = 0) >>> * Added patch to enable VHOST_NUMA by default. >>> >>> Version 2: >>> * rebased (fuzz in Makefile) >>> >>> Ilya Maximets (2): >>> mem: balanced allocation of hugepages >>> config: enable vhost numa awareness by default >>> >>> config/common_base | 1 + >>> config/common_linuxapp | 3 + >>> config/defconfig_arm-armv7a-linuxapp-gcc | 4 + >>> config/defconfig_arm64-armv8a-linuxapp-gcc | 4 + >>> config/defconfig_arm64-thunderx-linuxapp-gcc | 4 + >>> lib/librte_eal/linuxapp/eal/Makefile | 3 + >>> lib/librte_eal/linuxapp/eal/eal_memory.c | 105 ++++++++++++++++++++++++++- >>> mk/rte.app.mk | 3 + >>> 8 files changed, 123 insertions(+), 4 deletions(-) >>> > > > >