Re: [PATCH v5 25/36] mm/memory_hotplug: support N_MEMORY_PRIVATE node hotplug
Gregory Price <[email protected]>
| Newsgroups | org.kvack.linux-mm,dev.linux.lists.damon,dev.linux.lists.driver-core,dev.linux.lists.nvdimm,org.kernel.vger.cgroups,org.kernel.vger.kvm,org.kernel.vger.linux-cxl,org.kernel.vger.linux-debuggers,org.kernel.vger.linux-doc,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest |
|---|---|
| Message-ID | <aoJaaYp30LnKLj1w@gourry-fedora-PF4VCD3F> |
On Thu, Aug 06, 2026 at 11:30:08AM +0800, Qiqi Li wrote: > Hi Gregory, > > On 7/21/2026 3:34 AM, Gregory Price wrote: > > > Add add_private_memory_driver_managed() to let modules hotplug > > memory onto an N_MEMORY_PRIVATE node they control. > > I am trying to understand how the nid passed to > add_private_memory_driver_managed() is expected to be provisioned. > > From what I can see, both node_private_register() and > __add_memory_resource() require the nid to already be present in > node_possible_map. My understanding is therefore that this patch > supports hotplugging private memory onto an existing possible node, > rather than creating a new possible node ID at runtime. > > For example, in the use case I am looking at, the device's private > node is not described by firmware. Would its nid need to be reserved > during early NUMA initialization, or is there another mechanism that > I may have missed? > It would need to be reserved, and you could use numa emulation but that's clunky. I have an RFC for exactly this issue - though i haven't pushed it further yet. https://lore.kernel.org/all/[email protected]/ > Also, could you please Cc me on future revisions of this series? > I would appreciate it and would be happy to follow the work:) > > Thanks, > Qiqi