All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Pratyush Yadav <pratyush@kernel.org>
Cc: 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 09/12] memblock: introduce MEMBLOCK_KHO_SCRATCH_EXT
Date: Tue, 2 Jun 2026 16:20:02 +0300	[thread overview]
Message-ID: <ah7YgntNsAoFT4v_@kernel.org> (raw)
In-Reply-To: <2vxztsrlds0d.fsf@kernel.org>

On Tue, Jun 02, 2026 at 02:52:02PM +0200, Pratyush Yadav wrote:
> On Sun, May 31 2026, Mike Rapoport wrote:
> >> >
> >> > If we want to keep the naming aligned with the existing codebase for now:
> >> > MEMBLOCK_KHO_SCRATCH      -> original scratch
> >> > MEMBLOCK_KHO_UNPRESERVED  -> for the new memory (instead of SCRATCH_EXT)
> >> 
> >> UNPRESERVED sounds good to me. I will use that for the next revision
> >> unless Mike objects.
> >  
> > Can we make it shorter? ;-)
> >
> > UNPRESERVED makes sense, although I'd love to completely remove KHO_ notion
> > and make the name reflect how it's used by memblock. I was toying with
> > PREFERRED instead of SCRATCH, but it didn't feel right enough.
> > With two of them that surely won't work :)
> 
> I don't think you really can remove KHO_ notion. These memory regions
> only make sense on a KHO boot, and won't exist otherwise. And PREFERRED
> sounds like a suggestion/priority hint, not a hard limit. "With KHO
> boot, you can _only_ use PREFERRED memory", doesn't sound right...
> 
> I think MEMBLOCK_KHO_BOOTMEM for scratch and MEMBLOCK_KHO_NOPRESERVE
> (which I think is a tiny bit better than UNPRESERVED) for scratch_ext
> are my top picks. To make it shorter, perhaps MEMBLOCK_KHO_NOPRSRV, in
> similar fashion to RSRV_KERN?

There are a couple of unrelated 'bootmem' things in the kernel, adding
another one shouldn't hurt :)

I like MEMBLOCK_KHO_BOOTMEM and MEMBLOCK_KHO_NOPRSRV the most.
 
> >> would like this series to not get muddled in the naming discussion. I
> >> will use UNPRESERVED for the new concept in v2 though.
> >
> > That might warrant v3 even if everything else is perfect :)
> 
> I can live with that. As long as we can agree on the easy part (the
> code), I don't mind doing another version for the hard part (the naming)
> ;-)

It makes sense to keep KHO_SCRATCH for now and use MEMBLOCK_KHO_NOPRSRV for
the new one to begin with. And then we can ask an LLM do the renaming.
 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2026-06-02 13:20 UTC|newest]

Thread overview: 60+ 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-05 13:12       ` Pasha Tatashin
2026-05-11 11:32   ` Mike Rapoport
2026-05-11 16:25     ` Pratyush Yadav
2026-05-13 10:32       ` Mike Rapoport
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-05-21 23:27       ` Pasha Tatashin
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-05-21 23:31           ` Pasha Tatashin
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-05-21 23:34   ` Pasha Tatashin
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-05-21 23:37   ` Pasha Tatashin
2026-04-29 13:39 ` [PATCH 07/12] kho: allow destroying " Pratyush Yadav
2026-05-11 11:57   ` Mike Rapoport
2026-05-21 23:46   ` Pasha Tatashin
2026-05-22 13:24     ` Pratyush Yadav
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-05-22  0:48       ` Pasha Tatashin
2026-05-22 15:02         ` Pratyush Yadav
2026-05-31 18:51           ` Mike Rapoport
2026-06-02 12:52             ` Pratyush Yadav
2026-06-02 13:20               ` Mike Rapoport [this message]
2026-04-29 13:39 ` [PATCH 10/12] kho: extended scratch Pratyush Yadav
2026-05-17 10:17   ` Mike Rapoport
2026-05-18 17:04     ` 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
2026-05-17 10:05   ` Mike Rapoport
2026-05-25 15:24     ` Pratyush Yadav
2026-05-31 18:40       ` Mike Rapoport
2026-06-02 13:35         ` Pratyush Yadav
2026-06-02 17:50           ` 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=ah7YgntNsAoFT4v_@kernel.org \
    --to=rppt@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=pratyush@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.