From: Andrea Arcangeli <aarcange@redhat.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>, Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] mm: thp: Redefine default THP defrag behaviour disable it by default
Date: Thu, 25 Feb 2016 20:01:44 +0100 [thread overview]
Message-ID: <20160225190144.GE1180@redhat.com> (raw)
In-Reply-To: <1456420339-29709-1-git-send-email-mgorman@techsingularity.net>
On Thu, Feb 25, 2016 at 05:12:19PM +0000, Mel Gorman wrote:
> some cases, this will reduce THP usage but the benefit of THP is hard to
> measure and not a universal win where as a stall to reclaim/compaction is
It depends on the workload: with virtual machines THP is essential
from the start without having to wait half a khugepaged cycle in
average, especially on large systems. We see this effect for example
in postcopy live migraiton where --postcopy-after-precopy is essential
to reach peak performance during database workloads in guest,
immediately after postcopy completes. With --postcopy-after-precopy
only those pages that may be triggering userfaults will need to be
collapsed with khugepaged and all the rest that was previously passed
over with precopy has an high probability to be immediately THP backed
also thanks to defrag/direct-compaction. Failing at starting
the destination node largely THP backed is very visible in benchmark
(even if a full precopy pass is done first). Later on the performance
increases again as khugepaged fixes things, but it takes some time.
So unless we've a very good kcompatd or a workqueue doing the job of
providing enough THP for page faults, I'm skeptical of this. If
something I'd rather set defrag to "madvise" as qemu and other loads
that critically need THP or they run literally half as slow (for
example with enterprise workloads in the guest) will still be able not
to rely solely on khugepaged which can takes some time to act. So your
benchmark would run the same but the VM could still start fully THP
backed.
Another problem is that khugepaged isn't able to collapse shared
readonly anon pages, mostly because of the rmap complexities. I agree
with Kirill we should be looking into how make this work, although I
doubt the simpler refcounting is going to help much in this regard as
the problem is in dealing with rmap, not so much with refcounts.
--
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:[~2016-02-25 19:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-25 17:12 [PATCH 1/1] mm: thp: Redefine default THP defrag behaviour disable it by default Mel Gorman
2016-02-25 18:32 ` Rik van Riel
2016-02-25 19:07 ` Mel Gorman
2016-02-25 19:01 ` Andrea Arcangeli [this message]
2016-02-25 19:56 ` Mel Gorman
2016-02-25 23:02 ` Andrea Arcangeli
2016-02-25 23:08 ` Andrea Arcangeli
2016-02-26 11:13 ` Mel Gorman
2016-02-26 19:50 ` Andrea Arcangeli
2016-02-26 20:46 ` Mel Gorman
2016-02-26 10:32 ` Kirill A. Shutemov
2016-03-02 18:47 ` Andrea Arcangeli
2016-02-25 19:45 ` Johannes Weiner
2016-02-26 10:52 ` Mel Gorman
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=20160225190144.GE1180@redhat.com \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=riel@redhat.com \
--cc=vbabka@suse.cz \
/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 NNTP newsgroup(s).