From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by dpdk.org (Postfix) with ESMTP id 54F6A1396 for ; Wed, 22 Mar 2017 13:08:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1934; q=dns/txt; s=iport; t=1490184520; x=1491394120; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Pm1Rv9u0I4eL6H1rwFsyLIiZ1aPb0ZtwpHHx/BcGffI=; b=f0R5ClfMWpxfF8ANZoST8DR3+M0NM1+puJHcoudRgrZ+5gAPT4evWShe PtyTtj43q26V4EU3y3+7F2D+MmAaXAOLQI4SyZeDaIRARJ2Fffr1LDwkM q84KS8krMPDRnB5nEcucMAttXkM5mZmFZ5mlcXJomE7ukcl++kooFC0mq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAQD/Z9JY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDKBCoNiihBzkG6VR4IOKoV4AoNeGAECAQEBAQEBAWsohRUBAQE?= =?us-ascii?q?BAgEjFVELGAICJgICVwYBDAgBAYl4CA6qLIImij8BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEggQuFQ4IFgmqHWoJfAQScUYZ6i02CT4gKhlaPO4QlHziBBCQWCBcVhxs+NYo?= =?us-ascii?q?aAQEB?= X-IronPort-AV: E=Sophos;i="5.36,205,1486425600"; d="scan'208";a="693166182" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2017 12:08:39 +0000 Received: from [10.61.197.119] ([10.61.197.119]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2MC8cJQ005237; Wed, 22 Mar 2017 12:08:38 GMT To: Sergio Gonzalez Monroy , dev@dpdk.org References: <4a774c72-bd59-ea52-b65f-ed8cb0b8a700@cisco.com> <61219f8c-972d-3e18-6e75-57207d7e149c@intel.com> From: Ruslan Bilovol Message-ID: Date: Wed, 22 Mar 2017 14:08:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <61219f8c-972d-3e18-6e75-57207d7e149c@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [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: Wed, 22 Mar 2017 12:08:40 -0000 On 03/21/2017 04:41 PM, Sergio Gonzalez Monroy wrote: > The DPDK will still try to allocate contiguous hugepages. > Since DPDK v16.07 the mempool library is able to create a mempool with multiple chunks of memory. > You would still have the contig memory restriction for any other DPDK library or app. > > Are you pre-allocating hugepages on boot (kernel cmdline) or runtime? I tried both cases, and there is no much difference between them. (I used debug prints in kernel to see physical address of preallocated hugepages Main issue is that linux kernel memory allocation algorithm was changed with "fair zone allocator policy" commits, and in my case need to pre-allocate 2x or even 3x more hugepages now. Regards, Ruslan > > Sergio > > On 21/03/2017 14:20, Ruslan Bilovol wrote: >> 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 >> >