From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 25D2C6CCF for ; Wed, 25 Apr 2018 15:29:00 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2018 06:29:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,326,1520924400"; d="scan'208";a="50709688" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga001.jf.intel.com with ESMTP; 25 Apr 2018 06:28:59 -0700 Received: from irsmsx110.ger.corp.intel.com ([169.254.15.211]) by IRSMSX107.ger.corp.intel.com ([169.254.10.141]) with mapi id 14.03.0319.002; Wed, 25 Apr 2018 14:28:58 +0100 From: "Pattan, Reshma" To: "Burakov, Anatoly" , "dev@dpdk.org" CC: "Parthasarathy, JananeeX M" Thread-Topic: [PATCH v3 3/3] mem: improve autodetection of hugepage counts on 32-bit Thread-Index: AQHT27W+5auyymBzwE64U3UUCJ7/xqQRexxQ Date: Wed, 25 Apr 2018 13:28:57 +0000 Message-ID: <3AEA2BF9852C6F48A459DA490692831F2A2C9B5B@irsmsx110.ger.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3 3/3] mem: improve autodetection of hugepage counts on 32-bit 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, 25 Apr 2018 13:29:01 -0000 > -----Original Message----- > From: Burakov, Anatoly > Sent: Tuesday, April 24, 2018 11:19 AM > To: dev@dpdk.org > Cc: Pattan, Reshma > Subject: [PATCH v3 3/3] mem: improve autodetection of hugepage counts on > 32-bit >=20 > For non-legacy mode, we are preallocating space for hugepages, so we know > in advance which pages we will be able to allocate, and which we won't. > However, the init procedure was using hugepage counts gathered from sysfs > and paid no attention to hugepage sizes that were actually available for > reservation, and failed on attempts to reserve unavailable pages. >=20 > Fix this by limiting total page counts by number of pages actually > preallocated. >=20 > Also, VA preallocate procedure only looks at mountpoints that are availab= le, > and expects pages to exist if a mountpoint exists. That might not necessa= rily > be the case, so also check if there are hugepages available for a particu= lar > page size on a particular NUMA node. >=20 > Signed-off-by: Anatoly Burakov > --- >=20 Tested-by: Jananee Parthasarathy