From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140088.outbound.protection.outlook.com [40.107.14.88]) by dpdk.org (Postfix) with ESMTP id 318941B2AD for ; Thu, 29 Nov 2018 00:04:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VtecXh8L2+/QCC0L66gFX5Io/6PPXDedOelFD4nOTiA=; b=U7tQxANDeD7w4Jzev7OD3xW+ZYY5w/w6+juzjV40DnERghYzucnqsNaWRR+c9iBC1F1hdbbyANzFih8cjQFW9zIvwfiCR0iO7pqu0m0XtqzkFSg8M9qFAKv31lPCIoP700dgDFsvpCG3jvjm3bexy4S9YfEzxawGlraJ/aC1S9s= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4091.eurprd05.prod.outlook.com (52.134.68.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.20; Wed, 28 Nov 2018 23:04:35 +0000 Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::dcbc:4578:3018:50f3]) by DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::dcbc:4578:3018:50f3%4]) with mapi id 15.20.1361.019; Wed, 28 Nov 2018 23:04:35 +0000 From: Yongseok Koh To: Alejandro Lucero CC: dpdk stable , Eelco Chaudron , ovs dev , Kevin Traynor , "Burakov, Anatoly" Thread-Topic: [dpdk-stable] [PATCH 17.11] mem: fix memory initialization time Thread-Index: AQHUenlvZ2kZ737nVUqUcZPVh4Xj8aVl6ICA Date: Wed, 28 Nov 2018 23:04:35 +0000 Message-ID: References: <20181112111819.25087-1-alejandro.lucero@netronome.com> In-Reply-To: <20181112111819.25087-1-alejandro.lucero@netronome.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; x-originating-ip: [209.17.37.120] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0502MB4091; 6:GmvDAAwTcjlj6UuKjcF1VMpvbEc4cuD/YBzcD1Efmv3xmwIxZpYTtkUDUbFCOcyCHsw2oO9Q1Kkv5OcUbp2ogkKAB6Ee+mZOwn2xozvF/sZF6V/UCZw9IJmN5HXP8BCS4O1FURpVP8T230tM9zRnJ58d2f2OeZPtQKcA64AEnrTCaolsNIW6+u7flhJb4KnmiZeiMtBarQc5LyT/jBlBWOri7y80hMGC3SuWdLM53Ea+DqCUD8T9WSER5vWdSVH0/fBGUi2VQMS+Yc/9HAz6ugeFR5ATuATWDG1ypXEoMz2XKX5L9pohSLlj3mD4pwVGlx3OQTxR5IK9GI45S7KUO0YDUugD6rqTf+5FMfD5MEuFOsKvqn+NzS5Arg9o0GlOrjDRzBdoaXbRjdD3moATZB90kG/wEKa6j7i9HUI4tcNgjPvLNzSfkH7ferrXiZ/qT9//tCiCmcqFzrUt8ak4ig==; 5:cNv7lFauVNZ4EVunJA5IlSHCzqxvHyGWpvpr0WJDTXka6hCSmXhIQl/ACcORYl8+zNSjMxYZ29yO2L8ZBMq3wi7jOcMB+PrCsUKN77CbVIf/vY877I40no8XEzIdcsJ1l/qqGuhr10i6c9pQ0VaKJ7qf286/3qM0duejtbVELjs=; 7:/sftQdGZRz2Lqfs6Y6c2gcwihB7Iu0MvY7Syctr7ipwoiThZAnKii/aIuR6bY/QS2FABbNkhpKQyHnwuHiNnU2f3Tk2+9vcoqm9wSpIzgIMr6lfMiLNbCRZXi03raOGVQDIYJMx4dfQ/0jJIKDOEuw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4c10771a-8cf8-438d-d9b4-08d65585dd67 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB3PR0502MB4091; x-ms-traffictypediagnostic: DB3PR0502MB4091: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231443)(999002)(944501410)(52105112)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DB3PR0502MB4091; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0502MB4091; x-forefront-prvs: 0870212862 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(346002)(396003)(39860400002)(189003)(199004)(36756003)(6116002)(97736004)(71190400001)(106356001)(71200400001)(4326008)(68736007)(11346002)(186003)(105586002)(99286004)(82746002)(7736002)(5660300001)(8676002)(3846002)(83716004)(81156014)(14454004)(446003)(81166006)(478600001)(305945005)(86362001)(53936002)(33656002)(256004)(76176011)(575784001)(2616005)(476003)(6436002)(316002)(102836004)(6486002)(6506007)(39060400002)(486006)(6512007)(25786009)(6916009)(26005)(6246003)(66066001)(2906002)(229853002)(54906003)(8936002)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4091; H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: eKtJzSHO5LZWtQY8VVe14+GNrTmX2omrFBTWnlXR2HmcEqU2bBfRNzz6A2Jvhyj1x+W05GNB+Hm9HTiEnWJegrm5j+1jU0lQWIB3x7Mrt3PN8mbPPYWWAD8Fl3wzNWd1Dpp6SaYO2MtLaGe5lAB6bPOn2XXSu0DLi1/6fJTunCQsVqbWRi4FVuHrF8OtJYLx8+wrw7qMCKDjRp7J9MHaZt96pOBEuxOmRTfaJeuXYncT2UPGOFGRKE6iOHgGsJ43srVrb5AQDhMBiZYxBI8mOSszhcHjzKfoVSViiQ3d8GCgmgGsoGLKdhOMcG3UKaqI8i9Ckypq1H1QuYhu431/fWMI4TwejuCuKxC5v6bp/vY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <9EDAEB2670D12348821B14AA31655854@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c10771a-8cf8-438d-d9b4-08d65585dd67 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2018 23:04:35.1992 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB4091 Subject: Re: [dpdk-stable] [PATCH 17.11] mem: fix memory initialization time 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: Wed, 28 Nov 2018 23:04:37 -0000 > On Nov 12, 2018, at 3:18 AM, Alejandro Lucero wrote: >=20 > When using large amount of hugepage based memory, doing all the > hugepages mapping can take quite significant time. >=20 > The problem is hugepages being initially mmaped to virtual addresses > which will be tried later for the final hugepage mmaping. This causes > the final mapping requiring calling mmap with another hint address which > can happen several times, depending on the amount of memory to mmap, and > which each mmmap taking more than a second. >=20 > This patch changes the hint for the initial hugepage mmaping using > a starting address which will not collide with the final mmaping. >=20 > Fixes: 293c0c4b957f ("mem: use address hint for mapping hugepages") >=20 > Signed-off-by: Alejandro Lucero > --- Applied to stable/17.11 Thanks, Yongseok > lib/librte_eal/linuxapp/eal/eal_memory.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) >=20 > diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/li= nuxapp/eal/eal_memory.c > index bac969a12..0675809b7 100644 > --- a/lib/librte_eal/linuxapp/eal/eal_memory.c > +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c > @@ -421,6 +421,21 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl, = struct hugepage_info *hpi, > } > #endif >=20 > +#ifdef RTE_ARCH_64 > + /* > + * Hugepages are first mmaped individually and then re-mmapped to > + * another region for having contiguous physical pages in contiguous > + * virtual addresses. Setting here vma_addr for the first hugepage > + * mapped to a virtual address which will not collide with the second > + * mmaping later. The next hugepages will use increments of this > + * initial address. > + * > + * The final virtual address will be based on baseaddr which is > + * 0x100000000. We use a hint here starting at 0x200000000, leaving > + * another 4GB just in case, plus the total available hugepages memory. > + */ > + vma_addr =3D (char *)0x200000000 + (hpi->hugepage_sz * hpi->num_pages[0= ]); > +#endif > for (i =3D 0; i < hpi->num_pages[0]; i++) { > uint64_t hugepage_sz =3D hpi->hugepage_sz; >=20 > --=20 > 2.17.1 >=20