From: "Oscar Salvador (SUSE)" <osalvador@kernel.org>
To: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>, Qi Zheng <qi.zheng@linux.dev>,
Lance Yang <lance.yang@linux.dev>,
James Houghton <jthoughton@google.com>,
David Hildenbrand <david@kernel.org>,
Muchun Song <muchun.song@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 04/12] mm: hugetlb_vmemmap: generalize vmemmap page allocation
Date: Wed, 4 Nov 2026 10:58:09 +0100 [thread overview]
Message-ID: <ausBsbaw9DNVh4KA@localhost.localdomain> (raw)
In-Reply-To: <20261104023510.260766-5-songmuchun@bytedance.com>
On Wed, Nov 04, 2026 at 10:35:02AM +0800, Muchun Song wrote:
> Vmemmap page allocation is currently tied to restoring a virtual range
> and assumes an empty destination list. These constraints prevent it from
> being reused when pages are requested independently of a vmemmap range or
> appended to an existing list.
>
> Generalize the allocator and give it an all-or-nothing list contract so
> the restore and optimization paths can share the same allocation policy.
> This also allows HVO head-page allocation to fail gracefully under memory
> pressure without triggering the OOM killer.
>
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Qi Zheng <qi.zheng@linux.dev>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
A small nit below:
> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
> index 0e5b2b182d1b..d3058e106795 100644
> --- a/mm/hugetlb_vmemmap.c
> +++ b/mm/hugetlb_vmemmap.c
...
> +static int alloc_vmemmap_page_list(struct list_head *head,
> + unsigned int nr_pages, int nid)
> {
> - gfp_t gfp_mask = GFP_KERNEL | __GFP_RETRY_MAYFAIL;
> - unsigned long nr_pages = (end - start) >> PAGE_SHIFT;
> - int nid = page_to_nid((struct page *)start);
> + LIST_HEAD(new_pages);
> struct page *page, *next;
> - int i;
>
> - for (i = 0; i < nr_pages; i++) {
> - page = alloc_pages_node(nid, gfp_mask, 0);
> + for (unsigned int i = 0; i < nr_pages; i++) {
> + page = alloc_pages_node(nid, GFP_KERNEL | __GFP_RETRY_MAYFAIL, 0);
> if (!page)
> - goto out;
> - list_add(&page->lru, list);
> + goto free_pages;
> + list_add(&page->lru, &new_pages);
> }
> + list_splice(&new_pages, head);
> memmap_pages_add(nr_pages);
>
> return 0;
> -out:
> - list_for_each_entry_safe(page, next, list, lru)
> +free_pages:
> + list_for_each_entry_safe(page, next, &new_pages, lru)
> __free_page(page);
> return -ENOMEM;
> }
...
> @@ -527,15 +526,13 @@ static int __hugetlb_vmemmap_optimize_folio(const struct hstate *h,
> */
> folio_set_hugetlb_vmemmap_optimized(folio);
>
> - vmemmap_head = alloc_pages_node(nid, GFP_KERNEL, 0);
> - if (!vmemmap_head) {
> + if (alloc_vmemmap_page_list(vmemmap_pages, VMEMMAP_OPTIMIZATION_PAGES, nid)) {
> ret = -ENOMEM;
> goto out;
alloc_vmemmap_page_list() already gives you the error code (ENOMEM), so
it would look more natural to me to use that already and not "overwrite"
it.
e.g:
ret = alloc_vmemmap_page_list
if (ret)
goto out;
but as I said, just a nit :-)
--
Oscar Salvador
SUSE Labs
next prev parent reply other threads:[~2026-11-04 9:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 2:34 [PATCH v3 00/12] mm: Decouple folio-based vmemmap optimization from HugeTLB Muchun Song
2026-11-04 2:34 ` [PATCH v3 01/12] mm: hugetlb_vmemmap: remove HugeTLB-specific vmemmap optimization macros Muchun Song
2026-11-04 9:15 ` Oscar Salvador (SUSE)
2026-11-04 2:35 ` [PATCH v3 02/12] mm: hugetlb_vmemmap: unify VMEMMAP_{SPLIT,REMAP}_NO_TLB_FLUSH Muchun Song
2026-11-04 9:22 ` Oscar Salvador (SUSE)
2026-11-04 11:06 ` Mike Rapoport
2026-11-04 2:35 ` [PATCH v3 03/12] mm: hugetlb_vmemmap: simplify vmemmap head page handling Muchun Song
2026-11-04 9:40 ` Oscar Salvador (SUSE)
2026-11-04 2:35 ` [PATCH v3 04/12] mm: hugetlb_vmemmap: generalize vmemmap page allocation Muchun Song
2026-11-04 9:58 ` Oscar Salvador (SUSE) [this message]
2026-11-04 11:14 ` Muchun Song
2026-11-04 11:06 ` Mike Rapoport
2026-11-06 8:58 ` Muchun Song
2026-11-04 2:35 ` [PATCH v3 05/12] mm: hugetlb_vmemmap: unify writable vmemmap page preparation Muchun Song
2026-11-04 10:02 ` Oscar Salvador (SUSE)
2026-11-04 2:35 ` [PATCH v3 06/12] mm: hugetlb_vmemmap: rename vmemmap_remap_pte() to vmemmap_optimize_pte() Muchun Song
2026-11-04 10:04 ` Oscar Salvador (SUSE)
2026-11-04 2:35 ` [PATCH v3 07/12] mm: hugetlb_vmemmap: simplify shared tail page handling Muchun Song
2026-11-04 10:31 ` Oscar Salvador (SUSE)
2026-11-04 2:35 ` [PATCH v3 08/12] mm: hugetlb_vmemmap: move alloc_vmemmap_page_list() next to its free helper Muchun Song
2026-11-04 10:36 ` Oscar Salvador (SUSE)
2026-11-04 2:35 ` [PATCH v3 09/12] mm: hugetlb_vmemmap: make vmemmap optimization folio-oriented Muchun Song
2026-11-04 12:39 ` Oscar Salvador (SUSE)
2026-11-04 2:35 ` [PATCH v3 10/12] mm: hugetlb_vmemmap: make vmemmap restoration folio-oriented Muchun Song
2026-11-04 13:12 ` Oscar Salvador (SUSE)
2026-11-04 2:35 ` [PATCH v3 11/12] mm: hugetlb_vmemmap: unify vmemmap range restoration Muchun Song
2026-11-04 13:42 ` Oscar Salvador (SUSE)
2026-11-04 2:35 ` [PATCH v3 12/12] mm: hugetlb_vmemmap: make vmemmap PTE conversion folio-oriented Muchun Song
2026-11-05 9:26 ` Oscar Salvador (SUSE)
2026-11-06 8:50 ` Muchun Song
2026-11-04 6:46 ` [PATCH v3 00/12] mm: Decouple folio-based vmemmap optimization from HugeTLB Andrew Morton
2026-11-04 6:55 ` Muchun Song
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=ausBsbaw9DNVh4KA@localhost.localdomain \
--to=osalvador@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jthoughton@google.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=qi.zheng@linux.dev \
--cc=rppt@kernel.org \
--cc=songmuchun@bytedance.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 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.