From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by dpdk.org (Postfix) with ESMTP id 846A37E7C for ; Thu, 18 Dec 2014 15:21:20 +0100 (CET) Received: by mail-lb0-f180.google.com with SMTP id l4so1057915lbv.11 for ; Thu, 18 Dec 2014 06:21:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=51zucYrhgJy1UJNCy3eh8Cntaupc06x8X0JQPob6/3U=; b=fj/Tbegjotp+4eAmiK348WOfYzeJqrVtUCYVCv+avu4cm86UyjkRl/kgheKnPQwera QnHNlJZg6kDcr0rIAjRmunkPAz024VcDMPHjZ+RMs3TeCa12DG1aySD4Z62ef6l4Cx1x myiTiK2P8D82gCZ26IHEKGGr70PtPC+ODBn5LOZDFBheS1pRpIbAES/Rj1s8eXZEY5jy ATE6Dk7UWHSKH2GUaGTnyPu/6F+7AqAVg4SBPCi0TDqT2eVv9yucTs1uVye9fAmQ38jP OL8fL9kvdFbp56DY8eMXAqUrQ1HRBLtQLiyGGAfibXxQC6mpevbZlvLOkfhhqgBpOXp1 nkDA== X-Gm-Message-State: ALoCoQn7Jgm0zGJ34l+aX5oiv5hplPWnif/vcbrbdEQyCuzsamXZHNqYEsjLp6niDk1wUF2runY7 MIME-Version: 1.0 X-Received: by 10.112.235.196 with SMTP id uo4mr2513118lbc.66.1418912480083; Thu, 18 Dec 2014 06:21:20 -0800 (PST) Received: by 10.25.215.208 with HTTP; Thu, 18 Dec 2014 06:21:19 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Dec 2014 16:21:19 +0200 Message-ID: From: Alex Markuze To: Newman Poborsky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] rte_mempool_create fails with ENOMEM X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 14:21:20 -0000 I've Also seen a similar issue when trying to run a dpdk app which allocates huge pools(~0.5GB) after a memory heavy operation on the machine. I've come to the same conclusion as you did, that internal fragmentation is causing pool creation failures. It seems that the rte_mempool_xmem_create/rte_memzone_reserve_aligned are attempting to create physicaly contiguous pools. Which may offer a slight performance gain(?) but may cause unpredictable allocation issues which is a big risk for DC deployments where hundreds or even thousands of machines may be deployed with a dpdk app and fail inexplicably. I didn't really get the chance to digg into the memory managment internals of DPDK, so feel free to correct me where I'm off. Thanks. On Thu, Dec 18, 2014 at 3:25 PM, Newman Poborsky wrote: > > Hi, > > could someone please provide any explanation why sometimes mempool creation > fails with ENOMEM? > > I run my test app several times without any problems and then I start > getting ENOMEM error when creating mempool that are used for packets. I try > to delete everything from /mnt/huge, I increase the number of huge pages, > remount /mnt/huge but nothing helps. > > There is more than enough memory on server. I tried to debug > rte_mempool_create() call and it seems that after server is restarted free > mem segments are bigger than 2MB, but after running test app for several > times, it seems that all free mem segments have a size of 2MB, and since I > am requesting 8MB for my packet mempool, this fails. I'm not really sure > that this conclusion is correct. > > Does anybody have any idea what to check and how running my test app > several times affects hugepages? > > For me, this doesn't make any since because after test app exits, resources > should be freed, right? > > This has been driving me crazy for days now. I tried reading a bit more > theory about hugepages, but didn't find out anything that could help me. > Maybe it's something else and completely trivial, but I can't figure it > out, so any help is appreciated. > > Thank you! > > BR, > Newman P. >