From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www458.your-server.de (www458.your-server.de [136.243.165.62]) by sourceware.org (Postfix) with ESMTPS id 9F5E6385DC23; Sun, 3 May 2020 22:08:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9F5E6385DC23 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=conp-solutions.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nmanthey@conp-solutions.com Received: from sslproxy06.your-server.de ([78.46.172.3]) by www458.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1jVMmG-0004uY-Or; Mon, 04 May 2020 00:08:00 +0200 Received: from [92.117.118.30] (helo=nmanthey-ThinkPad-X1-Carbon-3rd.fritz.box) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jVMmG-000ATf-7y; Mon, 04 May 2020 00:08:00 +0200 From: Norbert Manthey To: libc-alpha@sourceware.org Cc: DJ Delorie , Carlos O'Donell , Siddhesh Poyarekar , Norbert Manthey Subject: [[RFC][PATCH] v1 0/2] malloc/realloc with transparent huge page support Date: Mon, 4 May 2020 00:07:06 +0200 Message-Id: <20200503220708.2048246-1-nmanthey@conp-solutions.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Authenticated-Sender: nmanthey@conp-solutions.com X-Virus-Scanned: Clear (ClamAV 0.102.2/25801/Sun May 3 14:08:15 2020) X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, GIT_PATCH_2, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 22:08:04 -0000 Dear all, I have been looking for a way to enable huge pages in a user land process without privileges, and without modifying the source of the process. Huge pages had to be used explicitly via linking against special libraries. An alternative are transparent huge pages, which are easier to obtain, but there are no guarantees of success. Using transparent huge pages can also result in slowdowns. Many Linux based distributions enable transparent huge pages via madvise, so that user land processes. With the madvise system call, a process can control whether allocated memory should be mapped with huge pages. However, the process typically only sees the allocations returned via a single malloc or realloc invocation, most of them being rather small. For a larger impact, I modified the way allocations are done behind the scenes. For the allocated memory, I changed the properties to (1) align to 2M instead of 4K, and (2) to call the madvise system call after the brk system call, to signal that the used memory area should be mapped with huge pages. The default behavior is not modified. The modification can currently be enabled, by specifying the environment variable GLIBC_THP_ALWAYS. ### Testing Done This change has been tested on top of glibc 2.23 in an Ubuntu 16.04 environment for programs that benefit from huge pages due to their large memory usage and pseudo-random memory access patterns (e.g. SAT solvers, model checkers, optimization tools an others). More details on the performance improvements for these tools can be found in https://arxiv.org/abs/2004.14378, e.g. page 9. #### glibc tests Both "make check" and "make xcheck" have not introduced regressions. I tested on a Ubuntu 20.04, with gcc-9.3 and an Intel(R) Core(TM) i7-5600U CPU. ### Stable branches I have a set of these patches to be applied to the 2.23 version of glibc. These patches had to be slightly adapted to be applicable to the current master branch. Intermediate versions of glibc might require small adaption. The patches for glibc-2.23 are available at: https://github.com/conp-solutions/thp/tree/master/ubuntu16.04-thp-env-2.23 Best, Norbert Norbert Manthey (2): malloc: support transparent huge pages malloc: improve THP effectiveness malloc/arena.c | 14 +++-- malloc/malloc.c | 144 ++++++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 143 insertions(+), 15 deletions(-) -- 2.25.1