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 99285A051C for ; Tue, 11 Feb 2020 12:30:38 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8B0B12BE9; Tue, 11 Feb 2020 12:30:38 +0100 (CET) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 4D6831BDAE for ; Tue, 11 Feb 2020 12:30:37 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id m16so11857841wrx.11 for ; Tue, 11 Feb 2020 03:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=DakZgIclaOmbjmqCm0w3x23G1mYL5UBRWSG3VbQlsVw=; b=quQLKPVdyJjh0AnqO9mUg00Y7Dp7cGAIOxWOL2nTJgeyFxBlVk+6kCQsMuD/BR42K8 BBg7GhsxG1kOufKU7mY9VEyYvzGxShCu44wToRVmZfSoR4Qafy12YpWqdIFs0pnBkVYY ELngxmvF4ReRT4zX3cV3VZ3USGmU2PNZjD8gwsQSDFbfZYUGO1BsSe1QoN0CFFltt1XL JKyPDo1T/lFFEmXfWKV0fd1XWXnxE/e2CrAMRWb+wK0AA02Tccn4kSbU8e72zsGiZjdg a00iJStb9mR1oPo1s5TVUVBDc7V9etLwEA+LhthrPyJ2hoPkZqyiHesrhH7jdUmuZk3H DB5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=DakZgIclaOmbjmqCm0w3x23G1mYL5UBRWSG3VbQlsVw=; b=qRVxi51vgofaLDAicZrK5rMPl72/4ifgfDgSLxwpaAibo0V5a6VnME/ch54lBnMeT8 0NIqrd7MUYiRVisOqHkq22V7Y4DXQNpo7A+WVCu/tpVMB0fLZbLNrgfxsrrzxIJmHy/n 9UpEd0NabbESG56Ihdpjn0znVaSUbvGNHaJ0dipLspLwXsCt8y6laQqzibq2LeGK4cwE Q4bkDnZ9Ghw/w9795Q0ywJe76QyoxUxEeCsQfubkmxReI1AgIbOPFHui5fKJYAnT08Ja sPDc1BszvdnER7TzAmrnkS3xUWfoj/6cjFtNrC5WNgMVRE6iiWJV37wPCcnmL/xEq2OL Udpg== X-Gm-Message-State: APjAAAVvZIod5KHBxBHaHa+fuDE1AtQV1VIvh8PXiwhqyQoHcpC+rncp h65+xdbbAfgOnp3JoG8bRH4= X-Google-Smtp-Source: APXvYqxn7DUqwOUiXiH/pFQmTNs5Bg5N2v2oCxN+clX0r9LwQbv156097f+FOiz/KAqc2Gfe3IYYqQ== X-Received: by 2002:a5d:4fce:: with SMTP id h14mr8850766wrw.60.1581420637016; Tue, 11 Feb 2020 03:30:37 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id c74sm3582372wmd.26.2020.02.11.03.30.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2020 03:30:36 -0800 (PST) From: luca.boccassi@gmail.com To: Olivier Matz Cc: Anatoly Burakov , Andrew Rybchenko , Ali Alnubani , dpdk stable Date: Tue, 11 Feb 2020 11:20:59 +0000 Message-Id: <20200211112216.3929-113-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200211112216.3929-1-luca.boccassi@gmail.com> References: <20200211112216.3929-1-luca.boccassi@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'mempool: fix slow allocation of large pools' has been queued to stable release 19.11.1 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, FYI, your patch has been queued to stable release 19.11.1 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 02/13/20. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Thanks. Luca Boccassi --- >From b019099e527f0ca0f120b32cb24845594c029cdd Mon Sep 17 00:00:00 2001 From: Olivier Matz Date: Fri, 17 Jan 2020 10:51:49 +0100 Subject: [PATCH] mempool: fix slow allocation of large pools [ upstream commit 3a3d0c75b43e8d1670c5ea6bf85cb3e1e60dfa2b ] 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") Signed-off-by: Olivier Matz Acked-by: Anatoly Burakov Reviewed-by: Andrew Rybchenko Tested-by: Ali Alnubani --- lib/librte_mempool/rte_mempool.c | 29 ++++++++++++----------------- 1 file changed, 12 insertions(+), 17 deletions(-) diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c index f8d453d21f..aea597224a 100644 --- a/lib/librte_mempool/rte_mempool.c +++ b/lib/librte_mempool/rte_mempool.c @@ -463,6 +463,7 @@ rte_mempool_populate_default(struct rte_mempool *mp) unsigned mz_id, n; int ret; bool need_iova_contig_obj; + size_t max_alloc_size = SIZE_MAX; ret = mempool_ops_alloc_once(mp); if (ret != 0) @@ -542,30 +543,24 @@ rte_mempool_populate_default(struct rte_mempool *mp) if (min_chunk_size == (size_t)mem_size) mz_flags |= RTE_MEMZONE_IOVA_CONTIG; - mz = rte_memzone_reserve_aligned(mz_name, mem_size, + /* Allocate a memzone, retrying with a smaller area on ENOMEM */ + do { + mz = rte_memzone_reserve_aligned(mz_name, + RTE_MIN((size_t)mem_size, max_alloc_size), mp->socket_id, mz_flags, align); - /* don't try reserving with 0 size if we were asked to reserve - * IOVA-contiguous memory. - */ - if (min_chunk_size < (size_t)mem_size && mz == NULL) { - /* not enough memory, retry with the biggest zone we - * have - */ - mz = rte_memzone_reserve_aligned(mz_name, 0, - mp->socket_id, mz_flags, align); - } + if (mz == NULL && rte_errno != ENOMEM) + break; + + max_alloc_size = RTE_MIN(max_alloc_size, + (size_t)mem_size) / 2; + } while (mz == NULL && max_alloc_size >= min_chunk_size); + if (mz == NULL) { ret = -rte_errno; goto fail; } - if (mz->len < min_chunk_size) { - rte_memzone_free(mz); - ret = -ENOMEM; - goto fail; - } - if (need_iova_contig_obj) iova = mz->iova; else -- 2.20.1 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2020-02-11 11:17:42.718460591 +0000 +++ 0113-mempool-fix-slow-allocation-of-large-pools.patch 2020-02-11 11:17:38.580004713 +0000 @@ -1,8 +1,10 @@ -From 3a3d0c75b43e8d1670c5ea6bf85cb3e1e60dfa2b Mon Sep 17 00:00:00 2001 +From b019099e527f0ca0f120b32cb24845594c029cdd Mon Sep 17 00:00:00 2001 From: Olivier Matz Date: Fri, 17 Jan 2020 10:51:49 +0100 Subject: [PATCH] mempool: fix slow allocation of large pools +[ upstream commit 3a3d0c75b43e8d1670c5ea6bf85cb3e1e60dfa2b ] + When allocating a mempool which is larger than the largest available area, it can take a lot of time: @@ -29,7 +31,6 @@ 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 Acked-by: Anatoly Burakov