From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 767A23B5 for ; Tue, 21 Mar 2017 15:41:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490107315; x=1521643315; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=ekpqhlQzvsnw6AenQvsr0MSTAz4G3EUczYxb/EjcQ6w=; b=Cto9DjNbW2W7GJE+81w6wT8FlmjYyE7jOytlR42YVqq5WVmqHrqf+rsK iJwKZO6J6w9wmyZ4lsniW7yqBhEUBg==; Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2017 07:41:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,198,1486454400"; d="scan'208";a="77776957" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.221.23]) ([10.237.221.23]) by orsmga005.jf.intel.com with ESMTP; 21 Mar 2017 07:41:51 -0700 To: Ruslan Bilovol , dev@dpdk.org References: <4a774c72-bd59-ea52-b65f-ed8cb0b8a700@cisco.com> From: Sergio Gonzalez Monroy Message-ID: <61219f8c-972d-3e18-6e75-57207d7e149c@intel.com> Date: Tue, 21 Mar 2017 14:41:50 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <4a774c72-bd59-ea52-b65f-ed8cb0b8a700@cisco.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: Tue, 21 Mar 2017 14:41:55 -0000 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? 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 >