linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Mike Rapoport <rppt@kernel.org>
Cc: lsf-pc@lists.linux-foundation.org,
	Alexander Graf <graf@amazon.com>,
	"Gowans, James" <jgowans@amazon.com>,
	linux-mm@kvack.org, David Rientjes <rientjes@google.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [LSF/MM/BPF TOPIC] memory persistence over kexec
Date: Mon, 20 Jan 2025 10:14:27 -0400	[thread overview]
Message-ID: <20250120141427.GK674319@ziepe.ca> (raw)
In-Reply-To: <Z44BJw_t8gDgUnLv@kernel.org>

On Mon, Jan 20, 2025 at 09:54:15AM +0200, Mike Rapoport wrote:
> Hi,
> 
> I'd like to discuss memory persistence across kexec.
> 
> Currently there is ongoing work on Kexec HandOver (KHO) [1] that allows
> serialization and deserialization of kernel data as well as preserving
> arbitrary memory ranges across kexec.
> 
> In addition, KHO keeps a physically contiguous memory regions that are
> guaranteed to not have any memory that KHO would preserve, but still can be
> used by the system. The kexeced kernel bootstraps itself using those
> regions and sets all handed over memory as in use. KHO users then can
> recover their state from the preserved data. This includes memory
> reservations, where the user can either discard or claim reservations.
> 
> KHO can be used as the base layer for implementation of persistence-aware
> memory allocator and persistent in-memory filesystem.
> 
> Aside from status update on KHO progress there are a few topics that I would
> like to discuss:
> * Is it feasible and desirable to enable KHO support in tmpfs and hugetlbfs?
> * Or is it better to implement yet another in-memory filesystem dedicated
>   for persistence?
> * What is the best way to ensure that the memory we want to persist is not
>   scattered all over the place?

There is alot of talk about taking *drivers* and having them survive
kexec, meaning the driver has to put alot of its state into KHO and
then get it back out again.

I've been hoping for a model where a driver can be told to "go to KHO"
and the KHO code can be largely contained in the driver and regulated
to recording the driver state. This implies the state may be
fragmented all over memory.

The other direction is that the driver has to start up in some special
KHO mode and KHO becomes invasive on all driver paths to use special
KHO allocations. This seems like a PITA.

You can see this difference just in the discussion around the iommu
serialization where one idea was to have KHO be an integral (and
invasive!) part of the page table operations from time zero vs some
later serialization at kexec time.

Regardless, I'm interested in this discussion to bring some
concreteness about how drivers work..

Jason


  reply	other threads:[~2025-01-20 14:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-20  7:54 Mike Rapoport
2025-01-20 14:14 ` Jason Gunthorpe [this message]
2025-01-20 19:42   ` David Rientjes
2025-01-22 23:30     ` Pasha Tatashin
2025-01-25  9:53       ` Mike Rapoport
2025-01-25 15:19         ` Pasha Tatashin
2025-01-26 20:04           ` Jason Gunthorpe
2025-01-26 20:41             ` Pasha Tatashin
2025-01-27  0:21               ` Alexander Graf
2025-01-27 13:15                 ` Jason Gunthorpe
2025-01-27 16:12                   ` Alexander Graf
2025-01-28 14:04                     ` Jason Gunthorpe
2025-01-27 13:05               ` Jason Gunthorpe
2025-01-24 21:03     ` Zhu Yanjun
2025-01-24 11:30   ` Mike Rapoport
2025-01-24 14:56     ` Jason Gunthorpe
2025-01-24 18:23 ` Andrey Ryabinin

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=20250120141427.GK674319@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=graf@amazon.com \
    --cc=jgowans@amazon.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=pasha.tatashin@soleen.com \
    --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