From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 63CC6CFA0 for ; Fri, 18 May 2018 15:10:06 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A13FB21BF5; Fri, 18 May 2018 09:10:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 18 May 2018 09:10:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=iieN4qgLz6r/WBIOWxIVV3jaFL wNlKmJAGn1r9Bs1Yo=; b=i93CR2OGkERr7MGBvPYhTMuPTHtez3qynr7J6BQ8py 7yZYIP/TQ0UO4DH3rw0nCOZsXqF9bTdPTqOI7Et5c6UGiq6pFHry8EtutPtJFWdl E6tHjeixDZqc6+5cCrZzfSZ3JF5zcY9O9MiDdtyADg+2NuEjsfqUPw//s/f12LYr Y= 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=iieN4q gLz6r/WBIOWxIVV3jaFLwNlKmJAGn1r9Bs1Yo=; b=iUldxBFsXqufwkcEIrA/0E oHk1ug74zPoLU3lhoHsNjlwWzkBB8hJjk1KDFD08nt574debnPAfgSFIj59gAFbU PTBGTXjxkO/K7ftbBlsQSGpoiklBf/M7LN+wBOvurrdWYeFt/CJ6S+MwM0zBYyUk IGLE+UxwS1k29UB4C1eKc0unGdrvshtK1WeBXbj71x8Wj199MheU2JiyiW+4qNl3 UtVbpVIPyJ4672boNgY3pYxvlQk5+MuOnwrGuxP34CSVv8IjxtCmX73G2ntKidoH p2o5QUuTNivbzdpCTadmYL9B4/Rw2aax6o2oq9c5zXQ5qeF2f21NjJGDi1Gv9pZQ == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A13F5E4EAC; Fri, 18 May 2018 09:10:04 -0400 (EDT) From: Thomas Monjalon To: Gowrishankar Cc: dev@dpdk.org, Anatoly Burakov , chaozhu@linux.vnet.ibm.com, pradeep@us.ibm.com Date: Fri, 18 May 2018 15:10:00 +0200 Message-ID: <3666379.S78H0t7kV9@xps> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 0/2] eal/malloc: fix wrong heap initialization over multiple memsegs 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: , X-List-Received-Date: Fri, 18 May 2018 13:10:06 -0000 Hi, What is the status of DPDK 18.05 on IBM POWER? This patch suggests there are some issues but there were no news for two weeks, after comments from Anatoly. Are we going to release a DPDK which does not work well on POWER? 03/05/2018 12:11, Gowrishankar: > When there are multiple memsegs (each per hugepage), there are couple of > problems observed: > > 1. Same heap size index is always chosen to add new malloc_elems > again and again, while there is an increasing heap size actually. > Hence, when there is memalloc request for size *more than* > elem->size available in free heap, malloc_heap_alloc would fail. > In elem_start_pt(), we are actually relying on elem->size at the > best, for finding suitable element, which is lower than requested > size, in this case. > > Hence, patch 1 in this series addresses this by merging > contiguous malloc_elem (by virt addresses), so that there is > better chance of finding suitable elem for the requested size. > > 2. Even after resizing the heap malloc_elems, its free_head index > is still the same, as the memsegs are just added in every malloc_ > elem. If larger memory is requested in rte_malloc, in a way > that, heap index of requested size is beyond the slot where the > entire heap is available, malloc_heap_alloc would fail. > Because, at the time of heap init, only the lower index is > always chosen to fill up memsegs. Hence, patch 2 addresses this > by moving the list of malloc_elems into new slot in heap, as its > size grows. > > We encountered these situations as we run ip_reassembly example app, > when multiple segments are created in VA (when overcommit hugepages set > in powerpc arch). > > These problems are found only in the current releases (until v18.05 > which carries new implementation for dynamic memory allocation). > These patches are tested with unit tests as well as some of the > examples apps. I request more testing if possible, on other archs > as these are problems in available LTS codes as well. > > Signed-off-by: Gowrishankar Muthukrishnan