From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ruslan Bilovol Subject: Is contiguous hugepages memory still required in latest DPDKs? Date: Tue, 21 Mar 2017 16:20:53 +0200 Message-ID: <4a774c72-bd59-ea52-b65f-ed8cb0b8a700@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: dev@dpdk.org 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) 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 List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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