From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: akpm@linux-foundation.org
Cc: muchun.song@linux.dev, osalvador@suse.de, david@redhat.com,
linmiaohe@huawei.com, naoya.horiguchi@nec.com, mhocko@kernel.org,
baolin.wang@linux.alibaba.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 3/3] docs: hugetlbpage.rst: add hugetlb migration description
Date: Tue, 27 Feb 2024 21:52:27 +0800 [thread overview]
Message-ID: <574e5bfbaa2b6930aad4a64e1c3da25c4ee5c9ee.1709041586.git.baolin.wang@linux.alibaba.com> (raw)
In-Reply-To: <cover.1709041586.git.baolin.wang@linux.alibaba.com>
Add some description of the hugetlb migration strategy.
Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
---
Documentation/admin-guide/mm/hugetlbpage.rst | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst
index e4d4b4a8dc97..f34a0d798d5b 100644
--- a/Documentation/admin-guide/mm/hugetlbpage.rst
+++ b/Documentation/admin-guide/mm/hugetlbpage.rst
@@ -376,6 +376,13 @@ Note that the number of overcommit and reserve pages remain global quantities,
as we don't know until fault time, when the faulting task's mempolicy is
applied, from which node the huge page allocation will be attempted.
+The hugetlb may be migrated between the per-node hugepages pool in the following
+scenarios: memory offline, memory failure, longterm pinning, syscalls(mbind,
+migrate_pages and move_pages), alloc_contig_range() and alloc_contig_pages().
+Now only memory offline, memory failure and syscalls allow fallbacking to allocate
+a new hugetlb on a different node if the current node is unable to allocate during
+hugetlb migration, that means these 3 cases can break the per-node hugepages pool.
+
.. _using_huge_pages:
Using Huge Pages
--
2.39.3
prev parent reply other threads:[~2024-02-27 13:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 13:52 [PATCH 0/3] make the hugetlb migration strategy consistent Baolin Wang
2024-02-27 13:52 ` [PATCH 1/3] mm: record the migration reason for struct migration_target_control Baolin Wang
2024-02-27 15:10 ` Oscar Salvador
2024-02-28 7:40 ` Baolin Wang
2024-02-27 13:52 ` [PATCH 2/3] mm: hugetlb: make the hugetlb migration strategy consistent Baolin Wang
2024-02-27 15:17 ` Oscar Salvador
2024-02-28 7:40 ` Baolin Wang
2024-02-28 8:41 ` Oscar Salvador
2024-03-06 8:35 ` Baolin Wang
2024-03-06 8:46 ` Oscar Salvador
2024-03-06 8:58 ` Baolin Wang
2024-02-27 13:52 ` Baolin Wang [this message]
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=574e5bfbaa2b6930aad4a64e1c3da25c4ee5c9ee.1709041586.git.baolin.wang@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=naoya.horiguchi@nec.com \
--cc=osalvador@suse.de \
/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