From: Andres Freund <andres@anarazel.de>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: James Hartshorn <jhartshorn@connexity.com>,
"Bridgman, John" <John.Bridgman@amd.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Can we disable transparent hugepages for lack of a legitimate use case please?
Date: Thu, 10 Sep 2015 19:02:53 +0200 [thread overview]
Message-ID: <20150910170253.GA6197@alap3.anarazel.de> (raw)
In-Reply-To: <20150910164506.GK10639@redhat.com>
On 2015-09-10 18:45:06 +0200, Andrea Arcangeli wrote:
> On Mon, Aug 24, 2015 at 08:46:11PM +0000, James Hartshorn wrote:
> > Some more links to discussion
> > about THP: Postgresql https://lwn.net/Articles/591723/ Postgresql
> > http://www.postgresql.org/message-id/20120821131254.1415a545@jekyl.davidgould.org
>
> "and my interpretation was that it was trying to create hugepages from
> scattered fragments"
>
> This is a very old email, but I'm just taking it as an example because
> this has to be a compaction issue. If you run into very visible hangs
> that goes away by disabling THP, it can't be THP to blame. THP can
> increase the latency jitter during page faults (real time sensitive
> application could notice a 2MB clear_page vs a 4KB clear_page), but
> not in a way that hangs a system and becomes visible to the user.
>
> It's just very early compaction code was too aggressive and it got
> fixed in the meanwhile.
There's still some slowdown (as of 4.0) in extreme postgres workloads
with THP and/or compaction enabled, but I've indeed not been able to
reproduce bad stalls or large (10%+) slowdowns with recent kernels.
Greetings,
Andres Freund
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-09-10 17:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-24 20:12 Can we disable transparent hugepages for lack of a legitimate use case please? James Hartshorn
2015-08-24 20:20 ` Bridgman, John
2015-08-24 20:46 ` James Hartshorn
2015-08-24 23:20 ` Theodore Ts'o
2015-09-10 16:45 ` Andrea Arcangeli
2015-09-10 17:02 ` Andres Freund [this message]
2015-09-14 12:37 ` Vlastimil Babka
2015-08-25 9:25 ` Konstantin Khlebnikov
2015-08-25 9:56 ` Vlastimil Babka
2015-09-01 22:26 ` David Rientjes
2015-09-02 8:55 ` Konstantin Khlebnikov
2015-09-02 9:06 ` Vlastimil Babka
2015-09-09 22:05 ` Andrea Arcangeli
2015-09-03 19:33 ` Andi Kleen
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=20150910170253.GA6197@alap3.anarazel.de \
--to=andres@anarazel.de \
--cc=John.Bridgman@amd.com \
--cc=aarcange@redhat.com \
--cc=jhartshorn@connexity.com \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.