From: Nico Pache <npache@redhat.com>
To: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Barry Song <baohua@kernel.org>,
Ryan Roberts <ryan.roberts@arm.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Lance Yang <ioworker0@gmail.com>, Peter Xu <peterx@redhat.com>,
Zi Yan <ziy@nvidia.com>, Rafael Aquini <aquini@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Jonathan Corbet <corbet@lwn.net>
Subject: [RFC 0/2] mm: introduce THP deferred setting
Date: Mon, 29 Jul 2024 16:27:25 -0600 [thread overview]
Message-ID: <20240729222727.64319-1-npache@redhat.com> (raw)
We've seen cases were customers switching from RHEL7 to RHEL8 see a
significant increase in the memory footprint for the same workloads.
Through our investigations we found that a large contributing factor to
the increase in RSS was an increase in THP usage.
For workloads like MySQL, or when using allocators like jemalloc, it is
often recommended to set /transparent_hugepages/enabled=never. This is
in part due to performance degradations and increased memory waste.
This series introduces enabled=defer, this setting acts as a middle
ground between always and madvise. If the mapping is MADV_HUGEPAGE, the
page fault handler will act normally, making a hugepage if possible. If
the allocation is not MADV_HUGEPAGE, then the page fault handler will
default to the base size allocation. The caveat is that khugepaged can
still operate on pages thats not MADV_HUGEPAGE.
This allows for two things... one, applications specifically designed to
use hugepages will get them, and two, applications that don't use
hugepages can still benefit from them without aggressively inserting
THPs at every possible chance. This curbs the memory waste, and defers
the use of hugepages to khugepaged. Khugepaged can then scan the memory
for eligible collapsing.
Admins may want to lower max_ptes_none, if not, khugepaged may
aggressively collapse single allocations into hugepages.
RFC note
==========
Im not sure if im missing anything related to the mTHP
changes. I think now that we have hugepage_pmd_enabled in
commit 00f58104202c ("mm: fix khugepaged activation policy") everything
should work as expected.
Nico Pache (2):
mm: defer THP insertion to khugepaged
mm: document transparent_hugepage=defer usage
Documentation/admin-guide/mm/transhuge.rst | 18 ++++++++++---
include/linux/huge_mm.h | 15 +++++++++--
mm/huge_memory.c | 31 +++++++++++++++++++---
3 files changed, 55 insertions(+), 9 deletions(-)
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Barry Song <baohua@kernel.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Lance Yang <ioworker0@gmail.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
--
2.45.2
next reply other threads:[~2024-07-29 22:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 22:27 Nico Pache [this message]
2024-07-29 22:27 ` [RFC 1/2] mm: defer THP insertion to khugepaged Nico Pache
2024-07-29 22:27 ` [RFC 2/2] mm: document transparent_hugepage=defer usage Nico Pache
2024-07-30 1:26 ` [RFC 0/2] mm: introduce THP deferred setting Zi Yan
2024-07-30 22:37 ` Nico Pache
2024-08-26 15:40 ` Nico Pache
2024-08-26 16:47 ` Usama Arif
2024-08-26 21:14 ` Nico Pache
2024-08-27 10:37 ` Usama Arif
2024-08-27 11:09 ` Johannes Weiner
2024-08-27 11:46 ` David Hildenbrand
2024-08-27 13:05 ` Johannes Weiner
2024-08-27 13:22 ` David Hildenbrand
2024-08-27 13:57 ` Usama Arif
2024-08-27 22:04 ` Nico Pache
2024-08-28 1:18 ` Rik van Riel
2024-08-28 6:17 ` Kirill A . Shutemov
2024-08-28 10:44 ` Usama Arif
2024-08-28 12:54 ` Rik van Riel
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=20240729222727.64319-1-npache@redhat.com \
--to=npache@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aquini@redhat.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=ioworker0@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=ryan.roberts@arm.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.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