From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 39D53A0555; Wed, 19 Feb 2020 16:42:49 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 746821B951; Wed, 19 Feb 2020 16:42:48 +0100 (CET) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by dpdk.org (Postfix) with ESMTP id D792B1B13C for ; Wed, 19 Feb 2020 16:42:46 +0100 (CET) Received: by mail-wm1-f49.google.com with SMTP id a5so1177724wmb.0 for ; Wed, 19 Feb 2020 07:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bY89TbbC8Dp8SuSKjTSNs++8+o0iuwSNxW3nSTCNxHw=; b=LJowt/0ZwcSBx2s/f3Y0WvFKrDqlCOoyuR0TfizGeLrNYfHwTg4WUxC8wLwvIWyrXK Lv6mdswbFTfji0Nf1TYZXVLJcDHYjR0rl1Ftm/S65otJKySR7h7CbT+4PWikKe6VVI0u f+OYthsstuRDcoT0EqXLm4+faMAqEnX/RVmSpOtnM/OPoMzyplqYqMZPUJZEDIK8CtVm mSkjUwEPq9jzIIRcM5i1UDbJ2oel5qoWSMBrwxe6t3hH6eK63mMZ0bv0+3wPTcM2Bhro c/FeOyKtRr+R4gwhtMIKf2qW/Z8W/Wsr/CS3zidPsFwi4JtiIbHr+BDVJkvHLwQBfppI yQCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bY89TbbC8Dp8SuSKjTSNs++8+o0iuwSNxW3nSTCNxHw=; b=oF607AC6zjkWzR5UTnkv+AQzJFxP3BSwnGMJEz0uxXaqatSlK7N0rvS+iXrI9x6m4n zQ2PKGdC+RZsZneuYBUo7M2IrimURxNFFdo6dWnKA2VwnAkZ/E5YmwBp14lSWjftKKRP GqXNMQ6ULjO0Q+HZme6Ti509eNXvaZw+BwwnskBNLVpdIDurjlinzvpOth0jliAvUrB2 0yjIrrHSeqrCQGP2rcEC08SgbwSnjUkuzYb6vi+bhNlZO3pRfB/HSomhuQaWiIk+xT5b zvE9Sa7my+QSNIyo/lL3oPLC7QVkSIvdFxrB6bcxCvclmahqSPB9f5J8jx1IHFLfPJ/w 6IaA== X-Gm-Message-State: APjAAAUZEgWMV2GEI8dbf2JNv8F+T83hgnOejWkk6p3fxsoCVn8NSA3e 8s4LfaJQtp/9zk0c+Z0n3NuYbfAyRlMUd3SVfy0= X-Google-Smtp-Source: APXvYqzqcogl9ZyHS8dXLKtRyKLWPwRp5GmqB8iMgA5GYvLVOv97cGRW4vuFl7mk4Wfq77QTjizp1BvLRl5kVUymBII= X-Received: by 2002:a1c:cc06:: with SMTP id h6mr11080275wmb.118.1582126966367; Wed, 19 Feb 2020 07:42:46 -0800 (PST) MIME-Version: 1.0 References: <5192f94a-e50a-7e61-2e33-a218a4b6b5b4@intel.com> <9c888eb0-2192-137c-da5c-97f30da5204a@intel.com> <56527d9f-b079-a580-4a80-2207c1822260@intel.com> In-Reply-To: From: Kamaraj P Date: Wed, 19 Feb 2020 21:12:34 +0530 Message-ID: To: "Burakov, Anatoly" Cc: Kevin Traynor , dev@dpdk.org, Nageswara Rao Penumarthy , "Kamaraj P (kamp)" , mtang2@cisco.com Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] CONFIG_RTE_MAX_MEM_MB fails in DPDK18.05 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Anatoly, Thanks for the suggestions. Yeah we have just changed in our application to invoke mlockall() before rte_eal_init(). Looks like it does not help either. if (mlockall(MCL_CURRENT | MCL_FUTURE)) { printf("Failed mlockall !! ******\n"); } ret = rte_eal_init(argc, args); Looks like still observing the struck issue when allocating virtual pages. EAL: Detected lcore 0 as core 0 on socket 0 EAL: Support maximum 128 logical core(s) by configuration. EAL: Detected 1 lcore(s) EAL: Detected 1 NUMA nodes EAL: open shared lib /usr/lib64/librte_pmd_ixgbe.so.2.1 EAL: open shared lib /usr/lib64/librte_pmd_e1000.so.1.1 EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or directory) EAL: VFIO PCI modules not loaded EAL: Probing VFIO support... EAL: Module /sys/module/vfio not found! error 2 (No such file or directory) EAL: VFIO modules not loaded, skipping VFIO support... EAL: Ask a virtual area of 0x2e000 bytes EAL: Virtual area found at 0x100000000 (size = 0x2e000) EAL: Setting up physically contiguous memory... EAL: Setting maximum number of open files to 4096 EAL: Detected memory type: socket_id:0 hugepage_sz:2097152 EAL: Creating 32 segment lists: n_segs:1024 socket_id:0 hugepage_sz:2097152 EAL: Ask a virtual area of 0xd000 bytes EAL: Virtual area found at 0x10002e000 (size = 0xd000) EAL: Memseg list allocated: 0x800kB at socket 0 EAL: Ask a virtual area of 0x80000000 bytes Could you please suggest if there is any other option which we need to try it out. Thanks, Kamaraj On Wed, Feb 19, 2020 at 8:58 PM Burakov, Anatoly wrote: > On 19-Feb-20 3:02 PM, Kamaraj P wrote: > > Thanks for the suggestions. We didnt have --mlockall parameter option in > > the rte_eal_init(). > > we have just tried the option and our application says an *unrecognized > > option*. > > Lets us check further on this and let you know. > > > > Thanks, > > Kamaraj > > > > No, that's not an EAL option, that's a testpmd option. However, that's > not really what i was asking. > > If you have a custom application, and that application called mlockall() > (with appropriate flags) before EAL init, that would make all pages > pinned, present and future. That means, if you mmap() anonymous memory > (like EAL init does), it will take a long time because all of that > memory will be pinned (and since it's 4K pages because at that point, > we're not using hugepages yet, that will indeed take a long time). > > -- > Thanks, > Anatoly >