From: Zhu Yanjun <yanjun.zhu@linux.dev>
To: Pratyush Yadav <pratyush@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Mike Rapoport <rppt@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jonathan Corbet <corbet@lwn.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
Alexander Graf <graf@amazon.com>,
David Matlack <dmatlack@google.com>,
David Rientjes <rientjes@google.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Samiullah Khawaja <skhawaja@google.com>,
Vipin Sharma <vipinsh@google.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-doc@vger.kernel.org, kexec@lists.infradead.org
Subject: Re: [RFC PATCH 00/10] liveupdate: hugetlb support
Date: Mon, 8 Dec 2025 20:43:22 -0800 [thread overview]
Message-ID: <48d0b46e-2b82-44b6-a717-94bc258a508d@linux.dev> (raw)
In-Reply-To: <20251206230222.853493-1-pratyush@kernel.org>
在 2025/12/6 15:02, Pratyush Yadav 写道:
> This series adds support for live updating hugetlb-backed memfd,
> including support for 1G huge pages. This allows live updating VMs which
> use hugepages to back VM memory.
>
> Please take a look at this patch series [0] to know more about the Live
> Update Orchestrator (LUO). It also includes patches for live updating a
> shmem-backed memfd. This series is a follow up to that, adding huge page
> support as well.
>
> You can also read this LWN article [1] to learn more about KHO and Live
> Update Orchestrator, though do note that this article is a bit
> out-of-date. LUO has since evolved. For example, subsystems have been
> replaced with FLB, and the state machine has been simplified.
>
> This series is based on top of mm-non-unstable, which includes the LUO
> FLB patches [2].
>
> This series uses LUO FLB to track how many pages are preserved for each
> hstate, to ensure the live updated kernel does not over-allocate
> hugepages.
Is this patch serise based on the patches in the link
https://lkml.org/lkml/2025/11/26/1665?
Thanks,
Yanjun.Zhu
>
> Areas for Discussion
> ====================
>
> Why is this an RFC?
> -------------------
>
> While I believe the code is in decent shape, I have only done some basic
> testing and have not put it through more intensive testing, including
> testing on ARM64. I am also not completely confident on the handling of
> reservations and cgroup charging, even though it appears to work on the
> surface.
>
> The goal of this is to start discussion at high level points so we can
> at least agree on the general direction. This also gives people some
> time to see the code, before the session discussing this at LPC 2025
> [3].
>
> Disabling scratch-only earlier in boot
> --------------------------------------
>
> Patch 2 moves KHO memory initialization to earlier in boot. Detailed
> discussion on the topic is in patch 2's message.
>
> Allocating gigantic hugepages after paging_init() on x86
> --------------------------------------------------------
>
> To allow KHO to work with gigantic hugepages on x86, patch 2 moves
> gigantic huge page allocation after paging_init(). This can have some
> impact on ability to allocate gigantic pages, but I believe the impact
> should not be severe. See patch 2 for more detailed discussion and test
> results.
>
> Early-boot access to LUO FLB data
> ---------------------------------
>
> To work with gigantic page allocation, LUO FLB data is needed in early
> boot, before LUO is fully initialized. Patch 3 adds support for fetching
> LUO FLB data in early boot.
>
> Preserving the entire huge page pool vs only used
> -------------------------------------------------
>
> This series makes a design decision on preserving only the number of
> preserved huge pages for each hstate, instead of preserving the entire
> huge page pool. Both approaches were brought up in the Live Update
> meetings. Patch 6 discusses the reasoning in more detail.
>
> [0] https://lore.kernel.org/linux-mm/20251125165850.3389713-1-pasha.tatashin@soleen.com/T/#u
> [1] https://lwn.net/Articles/1033364/
> [2] https://lore.kernel.org/linux-mm/20251125225006.3722394-1-pasha.tatashin@soleen.com/T/#u
> [3] https://lpc.events/event/19/contributions/2044/
>
> Pratyush Yadav (10):
> kho: drop restriction on maximum page order
> kho: disable scratch-only earlier in boot
> liveupdate: do early initialization before hugepages are allocated
> liveupdate: flb: allow getting FLB data in early boot
> mm: hugetlb: export some functions to hugetlb-internal header
> liveupdate: hugetlb subsystem FLB state preservation
> mm: hugetlb: don't allocate pages already in live update
> mm: hugetlb: disable CMA if liveupdate is enabled
> mm: hugetlb: allow freezing the inode
> liveupdate: allow preserving hugetlb-backed memfd
>
> Documentation/mm/memfd_preservation.rst | 9 +
> MAINTAINERS | 2 +
> arch/x86/kernel/setup.c | 19 +-
> fs/hugetlbfs/inode.c | 14 +-
> include/linux/hugetlb.h | 8 +
> include/linux/kho/abi/hugetlb.h | 98 ++++
> include/linux/liveupdate.h | 12 +
> kernel/liveupdate/Kconfig | 15 +
> kernel/liveupdate/kexec_handover.c | 13 +-
> kernel/liveupdate/luo_core.c | 30 +-
> kernel/liveupdate/luo_flb.c | 69 ++-
> kernel/liveupdate/luo_internal.h | 2 +
> mm/Makefile | 1 +
> mm/hugetlb.c | 113 ++--
> mm/hugetlb_cma.c | 7 +
> mm/hugetlb_internal.h | 50 ++
> mm/hugetlb_luo.c | 699 ++++++++++++++++++++++++
> mm/memblock.c | 1 -
> mm/memfd_luo.c | 4 -
> mm/mm_init.c | 15 +-
> 20 files changed, 1099 insertions(+), 82 deletions(-)
> create mode 100644 include/linux/kho/abi/hugetlb.h
> create mode 100644 mm/hugetlb_internal.h
> create mode 100644 mm/hugetlb_luo.c
>
>
> base-commit: 55b7d75112c25b3e2a5eadc11244c330a5c00a41
--
Best Regards,
Yanjun.Zhu
next prev parent reply other threads:[~2025-12-09 4:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-06 23:02 [RFC PATCH 00/10] liveupdate: hugetlb support Pratyush Yadav
2025-12-06 23:02 ` [RFC PATCH 01/10] kho: drop restriction on maximum page order Pratyush Yadav
2025-12-23 17:59 ` Pasha Tatashin
2025-12-29 21:24 ` Pratyush Yadav
2025-12-06 23:02 ` [RFC PATCH 02/10] kho: disable scratch-only earlier in boot Pratyush Yadav
2025-12-06 23:02 ` [RFC PATCH 03/10] liveupdate: do early initialization before hugepages are allocated Pratyush Yadav
2025-12-23 18:08 ` Pasha Tatashin
2025-12-29 21:23 ` Pratyush Yadav
2025-12-06 23:02 ` [RFC PATCH 04/10] liveupdate: flb: allow getting FLB data in early boot Pratyush Yadav
2025-12-18 18:25 ` Pasha Tatashin
2025-12-20 3:26 ` Pratyush Yadav
2025-12-20 15:11 ` Pasha Tatashin
2025-12-22 14:58 ` Pratyush Yadav
2025-12-06 23:02 ` [RFC PATCH 05/10] mm: hugetlb: export some functions to hugetlb-internal header Pratyush Yadav
2025-12-06 23:02 ` [RFC PATCH 06/10] liveupdate: hugetlb subsystem FLB state preservation Pratyush Yadav
2025-12-23 18:15 ` Pasha Tatashin
2025-12-29 21:21 ` Pratyush Yadav
2025-12-30 16:37 ` Pasha Tatashin
2025-12-06 23:02 ` [RFC PATCH 07/10] mm: hugetlb: don't allocate pages already in live update Pratyush Yadav
2025-12-06 23:02 ` [RFC PATCH 08/10] mm: hugetlb: disable CMA if liveupdate is enabled Pratyush Yadav
2025-12-23 18:16 ` Pasha Tatashin
2025-12-29 21:14 ` Pratyush Yadav
2025-12-06 23:02 ` [RFC PATCH 09/10] mm: hugetlb: allow freezing the inode Pratyush Yadav
2025-12-06 23:02 ` [RFC PATCH 10/10] liveupdate: allow preserving hugetlb-backed memfd Pratyush Yadav
2025-12-09 4:43 ` Zhu Yanjun [this message]
2025-12-09 8:18 ` [RFC PATCH 00/10] liveupdate: hugetlb support Pratyush Yadav
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=48d0b46e-2b82-44b6-a717-94bc258a508d@linux.dev \
--to=yanjun.zhu@linux.dev \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=dmatlack@google.com \
--cc=graf@amazon.com \
--cc=hpa@zytor.com \
--cc=jgg@nvidia.com \
--cc=kexec@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=skhawaja@google.com \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=vipinsh@google.com \
--cc=x86@kernel.org \
/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.