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 56555A04F9 for ; Thu, 9 Jan 2020 18:27:45 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2EB9F1E534; Thu, 9 Jan 2020 18:27:45 +0100 (CET) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id A91521E4C8 for ; Thu, 9 Jan 2020 18:27:42 +0100 (CET) Received: by mail-wr1-f65.google.com with SMTP id b6so8336921wrq.0 for ; Thu, 09 Jan 2020 09:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DjplXqjSJOLhRGXHkvIS8Un8pNeq+b0bX91itRqU9UQ=; b=Qib5t6hkIf1FAIBEbZqntPvLm5HqVO0tWrZ9OnGUYpgLBXiWZSKSVqSsGjTZyUuaAa s3aM6BEKQiL2jPkx5orniz/4nRciUCWDLsy5oI5z09HnQTlSRmxvugiPdMG7tgeoaGJY VgywZJQxNd029uR1dHnFgwirYrVAmFv4DW1FqpQry/ofBSfEIxXwn93ppBEdKF9JD8QA ctl4HcUWgC6UCccTzY+Ha0KZGJqMnXAwM4I5TPDzaGy1tcomBIMoswIvueE9YWS1/sQv 8Ugakp1RyrRIC74F8k6h3fjUYGLBIYDG5eY0Tt4A8d+Np6bwbIk9dtBUanir8ax7mGrB nj2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=DjplXqjSJOLhRGXHkvIS8Un8pNeq+b0bX91itRqU9UQ=; b=ix6uhMpnqa2NkvUSPkJyrGVLqc3DR1cnWUwhpQIBcd1zAsLxAkwxYzfumnkzvxMkL5 f6fo5dTEp5By8FOSKxIbf6ZqIa5f3iS6DoFVtEvJJR3CPI5jYO5TNxZQ3xQfBQTHcdox oPS80Mq85i7JujWpWyszdnDaYH67xEWA0oRuB6+T/csrF77V6PnUot+EnFNp3RVCXqo+ oyd6120D+aJNpmo6aLN7ApE4BNFrgwE46lR+NkTiQz9QhURHZSLtzmEzujvjH1Oq6YH9 K3wWZoAjCxRi2bgc5Bx1mwew4SDqaEeUCIjrWieZaqU8oAn2nBtDBu+Rif4rRbWpoTr3 4R4A== X-Gm-Message-State: APjAAAVyXNsCOqfjovsd/vcDnsghk4j1KNYZ14VAAQaFX0NvhR3TQeCN ef1tjLqaunZOv9A1u4b4yCnEwg== X-Google-Smtp-Source: APXvYqxHKW6vlw3rTWInQCg1TcxioJWe5SYjaapoWbb9dUmmzC7hAfkjRhS6ql06oM9L63rEipY3/Q== X-Received: by 2002:adf:9c8f:: with SMTP id d15mr12138340wre.390.1578590862420; Thu, 09 Jan 2020 09:27:42 -0800 (PST) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id z11sm8894400wrt.82.2020.01.09.09.27.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jan 2020 09:27:41 -0800 (PST) Date: Thu, 9 Jan 2020 18:27:41 +0100 From: Olivier Matz To: Ali Alnubani Cc: Andrew Rybchenko , Anatoly Burakov , "stable@dpdk.org" , "dev@dpdk.org" , Thomas Monjalon , Raslan Darawsheh Message-ID: <20200109172741.GL22738@platinum> References: <20200109132742.15828-1-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] mempool: fix slow allocation of large mempools X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi Ali, On Thu, Jan 09, 2020 at 04:06:53PM +0000, Ali Alnubani wrote: > Hi Olivier, > > > -----Original Message----- > > From: dev On Behalf Of Olivier Matz > > Sent: Thursday, January 9, 2020 3:28 PM > > To: dev@dpdk.org > > Cc: Andrew Rybchenko ; Anatoly Burakov > > ; stable@dpdk.org > > Subject: [dpdk-dev] [PATCH] mempool: fix slow allocation of large mempools > > > > When allocating a mempool which is larger than the largest available area, it > > can take a lot of time: > > > > a- the mempool calculate the required memory size, and tries > > to allocate it, it fails > > b- then it tries to allocate the largest available area (this > > does not request new huge pages) > > c- add this zone to the mempool, this triggers the allocation > > of a mem hdr, which request a new huge page > > d- back to a- until mempool is populated or until there is no > > more memory > > > > This can take a lot of time to finally fail (several minutes): in step > > a- it takes all available hugepages on the system, then release them after it > > fails. > > > > The problem appeared with commit eba11e364614 ("mempool: reduce > > wasted space on populate"), because smaller chunks are now allowed. > > Previously, it had to be at least one page size, which is not the case in step b-. > > > > To fix this, implement our own way to allocate the largest available area > > instead of using the feature from memzone: if an allocation fails, try to divide > > the size by 2 and retry. When the requested size falls below min_chunk_size, > > stop and return an error. > > > > Fixes: eba11e364614 ("mempool: reduce wasted space on populate") > > Cc: stable@dpdk.org > > > > Signed-off-by: Olivier Matz > > --- > > Testpmd (testpmd -n4 -- -i) fails to start after applying this patch with: > """ > EAL: Error - exiting with code: 1 > Cause: Creation of mbuf pool for socket 0 failed: File exists > """ > > This is why the check ci/iol-mellanox-Performance is failing (not sure if the other tests are failing for the same reason). Thanks for the report. I should have retested after my "little rework"... :) I'll send a v2 with this fix: --- a/lib/librte_mempool/rte_mempool.c +++ b/lib/librte_mempool/rte_mempool.c @@ -572,7 +572,7 @@ rte_mempool_populate_default(struct rte_mempool *mp) max_alloc_size = RTE_MIN(max_alloc_size, (size_t)mem_size) / 2; - } while (max_alloc_size >= min_chunk_size); + } while (mz == NULL && max_alloc_size >= min_chunk_size); if (mz == NULL) { ret = -rte_errno; Olivier