From: Pratyush Yadav <pratyush@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Pratyush Yadav <pratyush@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Alexander Graf <graf@amazon.com>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jason Miu <jasonmiu@google.com>,
kexec@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/12] kho: generalize radix tree APIs
Date: Mon, 11 May 2026 18:25:52 +0200 [thread overview]
Message-ID: <2vxz8q9pdib3.fsf@kernel.org> (raw)
In-Reply-To: <agG-OuOTAg5YD-CV@kernel.org> (Mike Rapoport's message of "Mon, 11 May 2026 14:32:10 +0300")
On Mon, May 11 2026, Mike Rapoport wrote:
> On Wed, Apr 29, 2026 at 03:39:03PM +0200, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>>
>> The KHO radix tree is a data structure that can track the presence or
>> absence of an arbitrary key, with nothing inherently tied to KHO memory
>> preservation tracking. This was one of the design goals of the radix
>> tree. This was done to enable it to be re-used by other users of KHO.
>>
>> Despite that, the radix tree APIs are very closely tied to KHO memory
>> preservation tracking. Adding a key is done by kho_radix_add_page(),
>> which encodes it as a page tracking operation and takes in PFN and
>> order. kho_radix_del_page() does the same. These functions encode the
>> key internally that goes into the radix tree. kho_radix_walk_tree() does
>> the same by baking the PFN and order into the callback arguments.
>>
>> Generalize the APIs by taking the key directly and doing the encoding at
>> the callers. Rename the functions to kho_radix_add_key() and
>> kho_radix_del_key(). In practice, this removes a line each from the
>> functions and moves the encoding function call to the callers.
>> Similarly, update kho_radix_tree_walk_callback_t to take the key
>> directly.
>>
>> To keep the naming convention clearer, rename
>> kho_radix_{encode,decode}_key() to kho_{encode,decode}_radix_key().
>>
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> ---
>> include/linux/kho_radix_tree.h | 18 +++----
>> kernel/liveupdate/kexec_handover.c | 76 ++++++++++++++----------------
>> 2 files changed, 42 insertions(+), 52 deletions(-)
>>
>> diff --git a/include/linux/kho_radix_tree.h b/include/linux/kho_radix_tree.h
>> index 84e918b96e53..f368f3b9f923 100644
>> --- a/include/linux/kho_radix_tree.h
>> +++ b/include/linux/kho_radix_tree.h
>> @@ -85,7 +85,7 @@ static struct kho_out kho_out = {
>> };
>>
>> /**
>> - * kho_radix_encode_key - Encodes a physical address and order into a radix key.
>> + * kho_encode_radix_key - Encodes a physical address and order into a radix key.
>
> Let's keep kho_radix_ prefix for namespasing please.
> This is the common practice these days.
I am keeping the namespacing, just moving it out of the "kho_radix"
namespace to "kho" namespace. The mental model is that this function has
nothing to do with the radix tree. It is just something KHO uses for one
of its radix tree, so it should live in the "kho" namespace not
"kho_radix".
Does that make sense? I can add this explanation to the commit message
as well.
>
>> * @phys: The physical address of the page.
>> * @order: The order of the page.
>> *
>
> ...
>
>> @@ -144,24 +144,21 @@ static unsigned long kho_radix_get_table_index(unsigned long key,
>> }
>>
>> /**
>> - * kho_radix_add_page - Marks a page as preserved in the radix tree.
>> + * kho_radix_add_key - Add a key to the radix tree.
>> * @tree: The KHO radix tree.
>> - * @pfn: The page frame number of the page to preserve.
>> - * @order: The order of the page.
>> + * @key: The key to add.
>> *
>> - * This function traverses the radix tree based on the key derived from @pfn
>> - * and @order. It sets the corresponding bit in the leaf bitmap to mark the
>> - * page for preservation. If intermediate nodes do not exist along the path,
>> - * they are allocated and added to the tree.
>> + * This function traverses the radix tree based on the key provided. It sets the
>
> Nit: @key here and in
> the comments below.
ACK.
>
>> + * corresponding bit in the leaf bitmap to mark the key as present. If
>> + * intermediate nodes do not exist along the path, they are allocated and added
>> + * to the tree.
>> *
>> * Return: 0 on success, or a negative error code on failure.
>> */
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2026-05-11 16:26 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 13:39 [PATCH 00/12] kho: make boot time huge page allocation work nicely with KHO Pratyush Yadav
2026-04-29 13:39 ` [PATCH 01/12] kho: generalize radix tree APIs Pratyush Yadav
2026-05-04 14:44 ` Pasha Tatashin
2026-05-05 11:20 ` Jork Loeser
2026-05-05 12:54 ` Pratyush Yadav
2026-05-11 11:32 ` Mike Rapoport
2026-05-11 16:25 ` Pratyush Yadav [this message]
2026-04-29 13:39 ` [PATCH 02/12] kho: store incoming radix tree in kho_in Pratyush Yadav
2026-05-11 11:43 ` Mike Rapoport
2026-05-11 16:28 ` Pratyush Yadav
2026-05-12 6:46 ` Mike Rapoport
2026-04-29 13:39 ` [PATCH 03/12] kho: add a struct for radix callbacks Pratyush Yadav
2026-05-11 11:47 ` Mike Rapoport
2026-05-11 16:35 ` Pratyush Yadav
2026-05-12 6:48 ` Mike Rapoport
2026-05-12 9:11 ` Pratyush Yadav
2026-04-29 13:39 ` [PATCH 04/12] kho: add callback for table pages Pratyush Yadav
2026-05-11 11:50 ` Mike Rapoport
2026-05-11 16:36 ` Pratyush Yadav
2026-05-11 16:40 ` Pratyush Yadav
2026-04-29 13:39 ` [PATCH 05/12] kho: add data argument to radix walk callback Pratyush Yadav
2026-05-11 11:53 ` Mike Rapoport
2026-05-11 16:37 ` Pratyush Yadav
2026-04-29 13:39 ` [PATCH 06/12] kho: allow early-boot usage of the KHO radix tree Pratyush Yadav
2026-05-11 11:56 ` Mike Rapoport
2026-05-11 16:37 ` Pratyush Yadav
2026-04-29 13:39 ` [PATCH 07/12] kho: allow destroying " Pratyush Yadav
2026-05-11 11:57 ` Mike Rapoport
2026-04-29 13:39 ` [PATCH 08/12] kho: add kho_radix_init_tree() Pratyush Yadav
2026-05-06 10:51 ` Jork Loeser
2026-05-11 11:05 ` Pratyush Yadav
2026-04-29 13:39 ` [PATCH 09/12] memblock: introduce MEMBLOCK_KHO_SCRATCH_EXT Pratyush Yadav
2026-05-11 12:06 ` Mike Rapoport
2026-05-11 16:46 ` Pratyush Yadav
2026-04-29 13:39 ` [PATCH 10/12] kho: extended scratch Pratyush Yadav
2026-04-29 13:39 ` [PATCH 11/12] kho: return virtual address of mem_map Pratyush Yadav
2026-05-11 12:13 ` Mike Rapoport
2026-05-11 16:48 ` Pratyush Yadav
2026-05-12 6:51 ` Mike Rapoport
2026-04-29 13:39 ` [PATCH 12/12] mm/hugetlb: make bootmem allocation work with KHO 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=2vxz8q9pdib3.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=graf@amazon.com \
--cc=jasonmiu@google.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.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