From: Zhu Yanjun <yanjun.zhu@linux.dev>
To: Pratyush Yadav <pratyush@kernel.org>,
linux-mm@kvack.org, lsf-pc@lists.linux-foundation.org
Cc: Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
David Rientjes <rientjes@google.com>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@kernel.org>,
Jason Gunthorpe <jgg@ziepe.ca>, Alexander Graf <graf@amazon.com>,
David Matlack <dmatlack@google.com>
Subject: Re: [LSF/MM/BPF TOPIC] HugeTLB file preservation across live update
Date: Wed, 4 Mar 2026 19:45:25 -0800 [thread overview]
Message-ID: <18666c09-1052-4a2c-8807-8ac330b4d918@linux.dev> (raw)
In-Reply-To: <2vxz1pixvk4m.fsf@kernel.org>
在 2026/2/6 9:48, Pratyush Yadav 写道:
> Hi all,
>
> I would like to propose the topic of HugeTLB file preservation across
> live update for discussion at the upcoming LSF/MM/BPF summit.
>
> Background
> ==========
>
> Support for performing a live update was recently added to the kernel
> via the Live Update Orchestrator (LUO) subsystem [0]. Live update allows
> a full kernel update over kexec without terminating running workloads.
> The main target is live updating the hypervisor without terminating VMs.
Regarding KHO/LUO, while the main target is VMs, the materials above
focus on updating the hypervisor itself. For physical machines,
performing live updates is much more challenging due to the large number
of physical devices—it's not clear how this is achieved. I’m very
interested in this topic and would like to attend the conference to
learn more about it.
Zhu Yanjun
>
> For more information on live update and LUO, see its kernel
> documentation [1], the LUO patchset [0], or this LPC 2025 presentation
> [2].
>
> MEMFD preservation
> ==================
>
> MEMFD is the first file type that added support for live update. This
> support was merged with the LUO series. The memfd preservation code can
> be found in mm/memfd_luo.c [3].
>
> MEMFD can use pages backed by shmem or HugeTLB. The live update support
> in mainline currently only works with shmem-backed MEMFDs.
>
> HugeTLB preservation
> ====================
>
> While shmem support for live update is useful for many things, using it
> for VM memory (and other memory-intensive workloads) is inefficient. The
> next step for MEMFD support for live update is to allow preserving
> HugeTLB-backed files.
>
> Note that we do not attempt to preserve the whole HugeTLB file system.
> We only preserve the memory pages for the files specified by userspace.
> The HugeTLB file is re-created fresh on the next kernel and the pages
> are inserted back in. This lets us keep the maintenance footprint
> smaller.
>
> Current status
> --------------
>
> This support was sent out on the list as an RFC [4] in December 2025,
> and was also presented at LPC 2025 [5] in the Live Update
> microconference.
>
> While the patchset has got some initial reviews from live update
> maintainers, it has not yet had any review from HugeTLB developers or
> maintainers.
>
> Goals of the discussion
> -----------------------
>
> This session will aim to present the topic, explain why it is needed,
> show how the support works, and most importantly, collect feedback on
> how to proceed with this work.
>
> PS: if any HugeTLB developers or maintainers are reading this, it would
> be great to have your initial thoughts on the RFC [4] so I can present a
> more polished patchset at the conference and make the most of the
> discussion.
>
> Key attendees
> =============
>
> Live update:
> - Alexander Graf
> - David Matlack
> - Jason Gunthorpe
> - Mike Rapoport
> - Pasha Tatashin
>
> HugeTLB:
> - David Hildenbrand
> - Muchun Song
> - Oscar Salvador
>
> References
> ==========
>
> [0] https://lore.kernel.org/linux-mm/20251125165850.3389713-1-pasha.tatashin@soleen.com/T/#u
> [1] https://docs.kernel.org/core-api/liveupdate.html
> [2] https://lpc.events/event/19/contributions/2052/
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/memfd_luo.c
> [4] https://lore.kernel.org/linux-mm/20251206230222.853493-1-pratyush@kernel.org/T/#u
> [5] https://lpc.events/event/19/contributions/2044/
>
prev parent reply other threads:[~2026-03-05 3:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 17:48 Pratyush Yadav
2026-02-07 16:21 ` Pasha Tatashin
2026-02-10 13:47 ` Pratyush Yadav
2026-03-05 3:45 ` Zhu Yanjun [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=18666c09-1052-4a2c-8807-8ac330b4d918@linux.dev \
--to=yanjun.zhu@linux.dev \
--cc=david@kernel.org \
--cc=dmatlack@google.com \
--cc=graf@amazon.com \
--cc=jgg@ziepe.ca \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--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 \
/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