From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id C6C323195; Sun, 28 Oct 2018 11:50:47 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5FE4E21E78; Sun, 28 Oct 2018 06:50:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 28 Oct 2018 06:50:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=5rwftvc5P6jnUGV3Vpw5T1DvaAJZXf5TdhaBxm00iLM=; b=X9THFnBcRSOF WtdJVSkjv893HCu2aQV2L9PQJDzyI6Mcu9GQRKX9S+gFSWmOM+K0yiQs9fQ82hiY dEU48yQYEZnXj//4bhqmRp6r5mSfc9w2DNdTWSBK/Z5yoE6RBzNihcqgzopr1add vvc2eHXR05wViAxebbfAexxQ5mR2Nnk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=5rwftvc5P6jnUGV3Vpw5T1DvaAJZXf5TdhaBxm00i LM=; b=OiaGXQ6trcTVe22luBMoP5bGfxz/u0cu5N4FiTfdD9Kj17kZM5b1EpW4u x6dBb+vHwaSS29SR5iOhirqAw3CTAPbppX6pEm5zdH7OFeMnH/Hel6y8u8Hcucui UKVFx+x0rFA3/vlgvFvwZiul6GOGpd+LZ1xceRnww1L+mAY0HO7UcGtkcZJrizk8 WG07x+ePFUFkHvXYun2OHbLo4ErxW9dss19QMVwc7I7Yca7IL9pZFbcz0tzxPin3 Ax1vCk0Jf9Qr37xORWhluHAQPhSVSX7+hh/g6BeErOLkQWTir7Esq/z5jC9OrKaB 5rjFTnNaGPMVto9UKh12bhR07o0hg== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 8E018E43AC; Sun, 28 Oct 2018 06:50:46 -0400 (EDT) From: Thomas Monjalon To: Darek Stojaczyk Cc: dev@dpdk.org, "Burakov, Anatoly" , stable@dpdk.org Date: Sun, 28 Oct 2018 11:50:52 +0100 Message-ID: <2067770.0L7xP8buvR@xps> In-Reply-To: <522e80af-e19e-2e5c-f1f1-6fd34075cf76@intel.com> References: <20181007193147.123868-1-dariusz.stojaczyk@intel.com> <522e80af-e19e-2e5c-f1f1-6fd34075cf76@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] malloc: respect SIZE_HINT_ONLY when looking for the biggest free elem 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: , X-List-Received-Date: Sun, 28 Oct 2018 10:50:48 -0000 08/10/2018 11:02, Burakov, Anatoly: > On 07-Oct-18 8:31 PM, Darek Stojaczyk wrote: > > RTE_MEMZONE_SIZE_HINT_ONLY wasn't checked in any way, > > causing size hints to be parsed as hard requirements. > > This resulted in some allocations being failed prematurely. > > > > Fixes: 68b6092bd3c7 ("malloc: allow reserving biggest element") > > Cc: anatoly.burakov@intel.com > > Cc: stable@dpdk.org > > > > Signed-off-by: Darek Stojaczyk > > --- > > lib/librte_eal/common/malloc_heap.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/lib/librte_eal/common/malloc_heap.c b/lib/librte_eal/common/malloc_heap.c > > index ac7bbb3ba..d2a8bd8dc 100644 > > --- a/lib/librte_eal/common/malloc_heap.c > > +++ b/lib/librte_eal/common/malloc_heap.c > > @@ -165,7 +165,9 @@ find_biggest_element(struct malloc_heap *heap, size_t *size, > > for (elem = LIST_FIRST(&heap->free_head[idx]); > > !!elem; elem = LIST_NEXT(elem, free_list)) { > > size_t cur_size; > > - if (!check_hugepage_sz(flags, elem->msl->page_sz)) > > + if ((flags & RTE_MEMZONE_SIZE_HINT_ONLY) == 0 && > > + !check_hugepage_sz(flags, > > + elem->msl->page_sz)) > > continue; > > Reviewed-by: Anatoly Burakov > > Although to be frank, the whole concept of "reserving biggest available > memzone" is currently broken because of dynamic memory allocation. There > is currently no way to allocate "as many hugepages as you can", so we're > only looking at memory already allocated, which in the general case is > less than page size long (unless you use legacy mode or memory > preallocation switches). Applied anyway, thanks