From mboxrd@z Thu Jan  1 00:00:00 1970
From: anupam <anupam.kapoor@gmail.com>
Subject: Re: Huge ring allocation
Date: Thu, 25 Aug 2016 18:19:42 +0530
Message-ID: <8737lt813t.fsf@fatcat.parallelwireless>
References: <9114674.mxuR5Pefat@polaris>
 <3F3704B6-4858-4967-960F-E5284F1B17CF@intel.com>
Mime-Version: 1.0
Content-Type: text/plain
Cc: "Wiles\, Keith" <keith.wiles@intel.com>, "dev\@dpdk.org" <dev@dpdk.org>
To: Gregory Etelson <gregory@weka.io>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pa0-f68.google.com (mail-pa0-f68.google.com
 [209.85.220.68]) by dpdk.org (Postfix) with ESMTP id 3E89E5591
 for <dev@dpdk.org>; Thu, 25 Aug 2016 14:49:47 +0200 (CEST)
Received: by mail-pa0-f68.google.com with SMTP id vy10so3083440pac.0
 for <dev@dpdk.org>; Thu, 25 Aug 2016 05:49:47 -0700 (PDT)
In-reply-to: <3F3704B6-4858-4967-960F-E5284F1B17CF@intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>


>>>>> [2016-08-25T17:52:26+0530]: "Keith Wiles" (keith-wiles):

,----[ keith-wiles ]
| Another issue sometimes is huge pages are allocated after the system
| has booted, which means you need to assign the number of huge pages very
| early in the boot process. This means adding a line in the sysctrl.conf
| file instead of poking the value later.
|
| vm.nr_hugepages=XXX
`----
you might also try passing 'hugepages' option as kernel command line
parameters e.g.

           '... hugepages=N '

from linux-kernel's Documentation/vm/hugetlbpage.txt we have the
following

,----[Documentation/vm/hugetlbpage.txt:69]
| The administrator can allocate persistent huge pages on the kernel boot
| command line by specifying the "hugepages=N" parameter, where 'N' = the
| number of huge pages requested.  This is the most reliable method of
| allocating huge pages as memory has not yet become fragmented.
`----


---
thanks
anupam