From mboxrd@z Thu Jan  1 00:00:00 1970
From: Yongseok Koh <yskoh@mellanox.com>
Subject: Re: [RFC v2 00/23] Dynamic memory allocation for DPDK
Date: Wed, 14 Feb 2018 02:01:56 +0000
Message-ID: <A7103C84-AF2F-4AF3-B87E-EB02F9B6BFFB@mellanox.com>
References: <cover.1513681966.git.anatoly.burakov@intel.com>
 <1513892309.2658.80.camel@intel.com>
 <c1a8f9f5-390d-c9ea-958a-85c0bcac60b3@intel.com>
 <1514308764.2658.93.camel@intel.com>
 <20180202192832.GA42096@yongseok-MBP.local>
 <afbeaf2a-3d5b-544e-d6ae-0d6b6d2f6023@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "Walker, Benjamin" <benjamin.walker@intel.com>, "dev@dpdk.org"
 <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
 "andras.kovacs@ericsson.com" <andras.kovacs@ericsson.com>, "Wiles, Keith"
 <keith.wiles@intel.com>, "Richardson, Bruce" <bruce.richardson@intel.com>,
 =?iso-8859-1?Q?N=E9lio_Laranjeiro?= <nelio.laranjeiro@6wind.com>, "Shahaf
 Shuler" <shahafs@mellanox.com>, "Xueming(Steven) Li" <xuemingl@mellanox.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from EUR03-DB5-obe.outbound.protection.outlook.com
 (mail-eopbgr40089.outbound.protection.outlook.com [40.107.4.89])
 by dpdk.org (Postfix) with ESMTP id CC4831B011
 for <dev@dpdk.org>; Wed, 14 Feb 2018 03:01:58 +0100 (CET)
In-Reply-To: <afbeaf2a-3d5b-544e-d6ae-0d6b6d2f6023@intel.com>
Content-Language: en-US
Content-ID: <5151656729FE59438E6F3A65891CD179@eurprd05.prod.outlook.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>


> On Feb 5, 2018, at 2:03 AM, Burakov, Anatoly <anatoly.burakov@intel.com> =
wrote:
>=20
> Thanks for your feedback, good to hear we're on the right track. I alread=
y have a prototype implementation of this working, due for v1 submission :)

Anatoly,

One more suggestion. Currently, when populating mempool, there's a chance t=
o
have multiple chunks if system memory is highly fragmented. However, with y=
our
new design, it is unlikely to happen unless the system is really low on mem=
ory.
Allocation will be dynamic and page by page. With your v2, you seemed to ma=
ke
minimal changes on mempool. If allocation fails, it will still try to gathe=
r
fragments from malloc_heap until it acquires enough objects and the resulta=
nt
mempool will have multiple chunks. But like I mentioned, it is very unlikel=
y and
this will only happen when the system is short of memory. Is my understandi=
ng
correct?

If so, how about making a change to drop the case where mempool has multipl=
e
chunks?

Thanks
Yongseok