public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: Norbert Manthey <nmanthey@conp-solutions.com>
Cc: libc-alpha@sourceware.org,  Siddhesh Poyarekar <siddhesh@sourceware.org>
Subject: Re: [[RFC][PATCH] v1 0/2] malloc/realloc with transparent huge page support
Date: Mon, 04 May 2020 09:07:52 +0200	[thread overview]
Message-ID: <87d07kw52v.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <dc5eb171-3514-c6aa-daf9-63262f3e2641@conp-solutions.com> (Norbert Manthey's message of "Mon, 4 May 2020 08:58:07 +0200")

* Norbert Manthey:

> I have seen [madvise] as the default for different Ubuntu versions
> (16.04, 18.04 and 20.04), so I expect it to be around for at least the
> next 5 years.

Still, it is easier to change a run-time kernel setting than to
upgrade glibc.

>> In the paper, you say this:
>>
>> | Because there might be applications running on the host that would
>> | suffer from larger pages, THP is usually disabled on physical
>> | systems and it is not advised to set the value to always.
>>
>> However, the default value for Red Hat Enterprise Linux 7 is, in fact,
>> "always", so it is puzzling why you see such a large benefit for
>> long-running processes.
>
> All used test systems have not been using [always], but [madvise]. For
> systems that already use [always], I expect the benefit to be much
> smaller. With the 2M alignment, there should be less 4K pages required,
> but we did not really measure the effect of only using the alignment.

I suggest to repeat the experiment with "always".  There is a reason
why this setting exists.  The results presented so far are incomplete.

The paper doesn't provide details on the NUMA configuration of the
test system, so one has to wonder if there are any surprises there as
well.

  reply	other threads:[~2020-05-04  7:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-03 22:07 Norbert Manthey
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 [this message]
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=87d07kw52v.fsf@mid.deneb.enyo.de \
    --to=fw@deneb.enyo.de \
    --cc=libc-alpha@sourceware.org \
    --cc=nmanthey@conp-solutions.com \
    --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).