From: Mike Rapoport <rppt@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Jason Miu <jasonmiu@google.com>, Alexander Graf <graf@amazon.com>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>,
Changyuan Lyu <changyuanl@google.com>,
David Matlack <dmatlack@google.com>,
David Rientjes <rientjes@google.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v4 1/2] kho: Adopt radix tree for preserved memory tracking
Date: Tue, 13 Jan 2026 16:46:01 +0200 [thread overview]
Message-ID: <aWZaqcStRAK6VWLy@kernel.org> (raw)
In-Reply-To: <20260113130526.GE812923@nvidia.com>
On Tue, Jan 13, 2026 at 09:05:26AM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 13, 2026 at 01:34:42PM +0200, Mike Rapoport wrote:
>
> > For example mshv intends to use kho_radix_tree to track the hypervisor
> > memory and there unpreserving will be a part of the normal flow.
>
> I do not think this is a good idea.
Sorry I wasn't clear, mshv is not going to use KHO memory tracker but
another instance of kho_radix_tree data structure.
I don't see a problem with that.
> Nothing should be touching KHO until a kexec sequence is started. KHO
> calls should WARN_ON prior to this point. If a kexec sequence aborts
> then the entire radix tree should be discarded and it should go back
> to WARN_ON'ing KHO calls.
The whole point of making KHO stateless was to decouple it from kexec
sequence and let userspace control when preservation happens and to allow
preserving as much as possible ahead of time to save cycles at
kexec-reboot.
> Jason
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2026-01-13 14:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 0:11 [PATCH v4 0/2] Make KHO Stateless Jason Miu
2026-01-09 0:11 ` [PATCH v4 1/2] kho: Adopt radix tree for preserved memory tracking Jason Miu
2026-01-12 10:15 ` Mike Rapoport
2026-01-12 14:39 ` Jason Gunthorpe
2026-01-13 11:34 ` Mike Rapoport
2026-01-13 13:05 ` Jason Gunthorpe
2026-01-13 14:46 ` Mike Rapoport [this message]
2026-01-13 14:58 ` Jason Gunthorpe
2026-01-13 16:16 ` Pasha Tatashin
2026-01-13 5:33 ` Jason Miu
2026-01-09 0:11 ` [PATCH v4 2/2] kho: Remove finalize state and clients Jason Miu
2026-01-12 10:25 ` Mike Rapoport
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=aWZaqcStRAK6VWLy@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=changyuanl@google.com \
--cc=dmatlack@google.com \
--cc=graf@amazon.com \
--cc=jasonmiu@google.com \
--cc=jgg@nvidia.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rientjes@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox