From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com
 [64.147.123.21]) by dpdk.org (Postfix) with ESMTP id C2DFB5B3E
 for <dev@dpdk.org>; Fri, 13 Jul 2018 11:06:48 +0200 (CEST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.west.internal (Postfix) with ESMTP id A18041BD;
 Fri, 13 Jul 2018 05:06:47 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute1.internal (MEProxy); Fri, 13 Jul 2018 05:06:47 -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=3L+6OeUfB7C1VQB6CvdzKm3MTc
 ninxlRiT5+uF1YkdQ=; b=aVLqndZ4ZNnRj/qBk8nfv+SFTS19J8X95TvL7l69dM
 ajiQvuIeBnix5toMFsK3LbWAbLL08izd0gvjyGyuUmZIjUQZ9pXevR4I12KyZiZA
 ti7rp0PcvKNtoxSpwje7IdT64SzwT0GSvteIFjltQqwCjZFn0F/mODdO/SK6oFJ5
 4=
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=fm3; bh=3L+6Oe
 UfB7C1VQB6CvdzKm3MTcninxlRiT5+uF1YkdQ=; b=LyHoT85hRYT+bOK3uvwRk6
 1qo9Yjcvd7a8nh7LbM7ka5y5v3iLDt4SpG1bLAcPm4K4K85i4BaTQnFv47M3XNc5
 NoGI4jx9Eqp7aGt7Y9nLxGQ9uB7VFlngS47honLV0vyoHisb2rTd/cWpHb/ue0Sj
 UDj9zJBK1/yUNZHX+BCr+zkgErR5JwU8Q58CTYcm49tXPIRer3KOhMP+KhUu6gsl
 x4jfd5aFUvx2YYz7ZkJ4wDA2CvmBANFcNcFLQQk99NKyD8SX9A/YTaAm71d4G6YO
 /tGcXPkXGeihq7VnuuQP3AtOnz/4x+De6nkCpsAM4d8cXUVNfyFca+dMB7dg4MBg
 ==
X-ME-Proxy: <xmx:p2tIWxUoJ0Pft20GvaQe3ef0yV9XV5591Bdrz8dWhm-qL9GABAnD3g>
 <xmx:p2tIW9A8oT14wHKcawQ4D-cD74e7iF17j1l48lVrsziSUKLlDG7k8A>
 <xmx:p2tIWw7Y9BEQdLj_KmC545PNLPpEd3lZFTaIrw6dlBEdHjScRSS1SA>
 <xmx:p2tIW4x4cQts1Sroe9t-vjc8w2OR7sr2W9KowfTf6Jon4wZWLr9FEA>
 <xmx:p2tIW3yuwP2MHNUxBE17wEvB1lubApO5LFuMuYADT3pUL9_yTX3W7g>
 <xmx:p2tIW459qbAQ2faoj_BQ-HepABOcnJAl9UwwgNn3BzBbMH4xlxa_0A>
X-ME-Sender: <xms:p2tIW8QjR0KWPDfbDX0yXFY77lguscJbyPQQvZ0s2GXehMc4L_0gLQ>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id B59B010255;
 Fri, 13 Jul 2018 05:06:46 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Anatoly Burakov <anatoly.burakov@intel.com>
Cc: dev@dpdk.org
Date: Fri, 13 Jul 2018 11:06:45 +0200
Message-ID: <2515509.GDSIbPj7Zt@xps>
In-Reply-To: <cover.1528749451.git.anatoly.burakov@intel.com>
References: <cover.1528749451.git.anatoly.burakov@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH 0/9] mem: reduce memory fragmentation
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2018 09:06:49 -0000

11/06/2018 22:55, Anatoly Burakov:
> This patchset is mostly dealing with changes fbarray, but it is
> actually about reducing fragmentation in Linuxapp memalloc.
> 
> We allocate hugepages from lower VA to higher VA. However, our
> malloc heap allocates addresses from higher VA to lower VA. This
> results in a situation where, whenever new page is allocated,
> malloc starts to allocate memory from the top, leaving fragmented
> space between new allocation's leftover and previous leftover.
> 
> Over time, this leads to lots of free elements sitting at page
> boundaries, small enough to be useful but large enough to have an
> impact on memory fragmentation in certain circumstances.
> 
> To fix this, we need to allocate memory from higher VA first.
> However, in order to do that, we need the ability to search fbarray
> in reverse, which is currently not supported. Adding this support is
> what most of this patchset is about.
> 
> First 4 patches fix some issues in existing fbarray implementation
> and remove some code duplication, preparing for adding of new
> functionality.
> 
> Next 3 patches add new functionality - reverse search of used/free
> slots, mirroring already existing functionality in semantics and
> capable of returning identical results but in reverse order.
> 
> Patch 8 adds unit tests for fbarray, testing both existing and new
> functionality.
> 
> Finally, patch 9 changes memalloc to look up free slots in memseg
> list in reverse order. No other changes is necessary, as all other
> code can handle segments, wherever they are allocated.
> 
> Anatoly Burakov (9):
>   fbarray: fix errno values returned from functions
>   fbarray: reduce duplication in find_contig code
>   fbarray: reduce duplication in find_next_n code
>   fbarray: reduce duplication in find_next code
>   fbarray: add reverse find_free/used
>   fbarray: add reverse find n used/free
>   fbarray: add reverse find contig used/free
>   test: add fbarray autotests
>   memalloc: allocate memory in reverse

Applied, thanks