From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by dpdk.org (Postfix) with ESMTP id C3EB311C5 for ; Tue, 21 Mar 2017 15:20:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1059; q=dns/txt; s=iport; t=1490106055; x=1491315655; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=PxioLbQI0wI2bk8AecaHFTSmPSvRzHFvdERHoJpkDuc=; b=aln47zNJK4c4bNenqgkQN6L3dXWnJb3kCnfSOUFXN7XSaJ7earfLOmOA TvKKeqmVpkTu2MDzqjT0uofghrE1WW9DfGYKlMQp1F45Tr983QmyGKOn8 HqFtxybRxOqyIwFeWqsGOMci+LLCx4dWDlHTqlxoCi0mnynLYJHeY3/qk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxDAAkNtFY/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhDIqYINiiwOmL4IOKolMFwECAQEBAQEBAWsohT8VdgImAmwIAQGKAA6?= =?us-ascii?q?aa5AGgiaLAoELhUOCBYgKgjqCXwWcUIZ6i0yCT4gIhlaPOoQlIQMzPkYjFggXF?= =?us-ascii?q?YcaPjWJQQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,198,1486425600"; d="scan'208";a="653420843" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2017 14:20:54 +0000 Received: from [10.61.197.91] ([10.61.197.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2LEKs8J014283 for ; Tue, 21 Mar 2017 14:20:54 GMT From: Ruslan Bilovol To: dev@dpdk.org Message-ID: <4a774c72-bd59-ea52-b65f-ed8cb0b8a700@cisco.com> Date: Tue, 21 Mar 2017 16:20:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [dpdk-dev] Is contiguous hugepages memory still required in latest DPDKs? 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, 21 Mar 2017 14:20:55 -0000 Hi, Recently after moving to 4.4 Linux kernel we found that DPDK v16.07 can't find physically contiguous chunk of hugepages memory. I've tracked this down to kernel commits 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy") fff4068cba48 ("mm: page_alloc: revert NUMA aspect of fair allocation policy") 4ffeaf3560a5 ("mm: page_alloc: reduce cost of the fair zone allocation policy") These commits changed default page allocator behavior so it now allocates memory proportionally from preferred and lower zones. Hugepages are scattered proportionally among few memory zones, so possibility to find big physically contiguous chunk of hugepages memory is much lower. I see that there were some attempts to move from contiguous hugepages approach, like http://dpdk.org/ml/archives/dev/2016-March/035201.html Also some discussion here: http://dpdk.org/ml/archives/users/2016-October/001050.html The question: is contiguous hugepages memory still required in latest DPDKs, and if not, since which version? Thanks, Ruslan