From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 889DBF72 for ; Tue, 24 Jul 2018 12:03:55 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2018 03:03:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,397,1526367600"; d="scan'208";a="247869559" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by fmsmga005.fm.intel.com with ESMTP; 24 Jul 2018 03:03:49 -0700 Received: from sivswdev01.ir.intel.com (sivswdev01.ir.intel.com [10.237.217.45]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id w6OA3m39030668; Tue, 24 Jul 2018 11:03:48 +0100 Received: from sivswdev01.ir.intel.com (localhost [127.0.0.1]) by sivswdev01.ir.intel.com with ESMTP id w6OA3ms8007132; Tue, 24 Jul 2018 11:03:48 +0100 Received: (from aburakov@localhost) by sivswdev01.ir.intel.com with LOCAL id w6OA3mBk007128; Tue, 24 Jul 2018 11:03:48 +0100 From: Anatoly Burakov To: dev@dpdk.org Cc: Thomas Monjalon , Ravi1.Kumar@amd.com Date: Tue, 24 Jul 2018 11:03:48 +0100 Message-Id: <40cf48703f5fae8af8c31dcc8a1a1ecb0b151d27.1532426170.git.anatoly.burakov@intel.com> X-Mailer: git-send-email 1.7.0.7 Subject: [dpdk-dev] [PATCH] config: reduce memory requirements for DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 10:03:57 -0000 It has been reported that current memory limitations do not work well on an 8-socket machines in default configuration when big page sizes are used [1]. Fix it by reducing memory amount reserved by DPDK by default to 32G per page size per NUMA node. This translates to allowing us to reserve 32G per page size per NUMA node on 8 nodes with 2 page sizes. [1] https://mails.dpdk.org/archives/dev/2018-July/108071.html Signed-off-by: Anatoly Burakov --- Notes: We could have increased CONFIG_RTE_MAX_MEM_MB but this would've brought other potential problems due to increased memory preallocation, and secondary process initialization is flaky enough as it is. I am willing to bet that 32G per page size is more than enough for the majority of use cases, and any application with bigger requirements could adjust config options itself. config/common_base | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config/common_base b/config/common_base index 201cdf698..78a644fb2 100644 --- a/config/common_base +++ b/config/common_base @@ -71,8 +71,8 @@ CONFIG_RTE_MAX_MEM_MB_PER_LIST=32768 # over multiple lists of RTE_MAX_MEMSEG_PER_LIST pages), or # RTE_MAX_MEM_MB_PER_TYPE megabytes of memory (split over multiple lists of # RTE_MAX_MEM_MB_PER_LIST), whichever is smaller -CONFIG_RTE_MAX_MEMSEG_PER_TYPE=32768 -CONFIG_RTE_MAX_MEM_MB_PER_TYPE=131072 +CONFIG_RTE_MAX_MEMSEG_PER_TYPE=16384 +CONFIG_RTE_MAX_MEM_MB_PER_TYPE=32768 # global maximum usable amount of VA, in megabytes CONFIG_RTE_MAX_MEM_MB=524288 CONFIG_RTE_MAX_MEMZONE=2560 -- 2.17.1