public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Norbert Manthey <nmanthey@conp-solutions.com>
To: libc-alpha@sourceware.org
Cc: DJ Delorie <dj@redhat.com>, Carlos O'Donell <carlos@redhat.com>,
	Siddhesh Poyarekar <siddhesh@sourceware.org>,
	Norbert Manthey <nmanthey@conp-solutions.com>
Subject: [[RFC][PATCH] v1 0/2] malloc/realloc with transparent huge page support
Date: Mon,  4 May 2020 00:07:06 +0200	[thread overview]
Message-ID: <20200503220708.2048246-1-nmanthey@conp-solutions.com> (raw)

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


             reply	other threads:[~2020-05-03 22:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-03 22:07 Norbert Manthey [this message]
2020-05-03 22:07 ` [[RFC][PATCH] v1 1/2] malloc: support transparent huge pages Norbert Manthey
2020-05-03 22:07 ` [[RFC][PATCH] v1 2/2] malloc: improve THP effectiveness Norbert Manthey
2020-05-03 22:21   ` Andrew Pinski
2020-05-03 22:15 ` [[RFC][PATCH] v1 0/2] malloc/realloc with transparent huge page support H.J. Lu
2020-05-04  4:36 ` Florian Weimer
2020-05-04  6:58   ` Norbert Manthey
2020-05-04  7:07     ` Florian Weimer
2020-05-04 21:07 ` DJ Delorie
2020-05-04 21:44   ` Norbert Manthey
     [not found] <7bd30e6c-7ae8-4c03-a818-6309351b3df9@email.android.com>
2020-05-04  8:27 ` Florian Weimer
2020-05-04 13:31   ` Adhemerval Zanella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200503220708.2048246-1-nmanthey@conp-solutions.com \
    --to=nmanthey@conp-solutions.com \
    --cc=carlos@redhat.com \
    --cc=dj@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=siddhesh@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).