From: Vlastimil Babka <vbabka@suse.cz>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>
Subject: [RFC v2 0/4] Outsourcing compaction for THP allocations to kcompactd
Date: Thu, 2 Jul 2015 10:46:31 +0200 [thread overview]
Message-ID: <1435826795-13777-1-git-send-email-vbabka@suse.cz> (raw)
This RFC series is another evolution of the attempt to deal with THP
allocations latencies. Please see the motivation in the previous version [1]
The main difference here is that I've bitten the bullet and implemented
per-node kcompactd kthreads - see Patch 1 for the details of why and how.
Trying to fit everything into khugepaged was getting too clumsy, and kcompactd
could have more benefits, see e.g. the ideas here [2]. Not everything is
implemented yet, though, I would welcome some feedback first.
The devil will be in the details of course, i.e. how to steer the kcompactd
activity. Ideally it should take somehow into account the amount of free memory,
its fragmentation, pressure for high-order allocations including hugepages,
past successes/failures of compaction, the CPU time spent... not an easy task.
Suggestions welcome :)
I briefly tested it with mmtests/thpscale, but I don't think the results are
that interesting at this moment.
The patchset is based on v4.1, next would probably conflict in at least
mempolicy.c. I know it's still merge window, but didn't want to delay 2 weeks
due to upcoming vacation. Thanks.
[1] https://lwn.net/Articles/643891/
[2] http://article.gmane.org/gmane.linux.kernel/1982369
Vlastimil Babka (4):
mm, compaction: introduce kcompactd
mm, thp: stop preallocating hugepages in khugepaged
mm, thp: check for hugepage availability in khugepaged
mm, thp: check hugepage availability for fault allocations
include/linux/compaction.h | 13 +++
include/linux/mmzone.h | 8 ++
mm/compaction.c | 207 +++++++++++++++++++++++++++++++++++++++++++++
mm/huge_memory.c | 180 +++++++++++++++++++--------------------
mm/internal.h | 39 +++++++++
mm/memory_hotplug.c | 15 ++--
mm/mempolicy.c | 42 +++++----
mm/page_alloc.c | 6 ++
mm/vmscan.c | 7 ++
9 files changed, 403 insertions(+), 114 deletions(-)
--
2.4.3
--
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 reply other threads:[~2015-07-02 8:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-02 8:46 Vlastimil Babka [this message]
2015-07-02 8:46 ` [RFC 1/4] mm, compaction: introduce kcompactd Vlastimil Babka
2015-07-09 21:53 ` David Rientjes
2015-07-21 9:03 ` Vlastimil Babka
2015-07-21 23:07 ` David Rientjes
2015-07-22 15:23 ` Vlastimil Babka
2015-07-22 22:36 ` David Rientjes
2015-07-23 9:18 ` Vlastimil Babka
2015-07-23 21:21 ` David Rientjes
2015-07-24 6:16 ` Joonsoo Kim
2015-07-24 6:45 ` Vlastimil Babka
2015-07-29 0:33 ` David Rientjes
2015-07-29 6:34 ` Vlastimil Babka
2015-07-29 21:54 ` David Rientjes
2015-07-29 23:57 ` Dave Chinner
2015-07-23 6:03 ` Joonsoo Kim
2015-07-23 20:58 ` David Rientjes
2015-07-24 5:33 ` Joonsoo Kim
2015-07-30 10:58 ` Mel Gorman
2015-07-31 21:17 ` David Rientjes
2015-07-02 8:46 ` [RFC 2/4] mm, thp: stop preallocating hugepages in khugepaged Vlastimil Babka
2015-07-02 8:46 ` [RFC 3/4] mm, thp: check for hugepage availability " Vlastimil Babka
2015-07-02 8:46 ` [RFC 4/4] mm, thp: check hugepage availability for fault allocations Vlastimil Babka
2015-07-24 14:22 ` [RFC v2 0/4] Outsourcing compaction for THP allocations to kcompactd Rik van Riel
2015-07-27 9:30 ` Vlastimil Babka
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=1435826795-13777-1-git-send-email-vbabka@suse.cz \
--to=vbabka@suse.cz \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
/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