Re: [PATCH v2 2/3] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Mon, 2023-07-24 at 13:54 +0800, Huang, Ying wrote: > Vishal Verma writes: > > > > > @@ -2035,12 +2056,38 @@ void try_offline_node(int nid) > >  } > >  EXPORT_SYMBOL(try_offline_node); > >   > > -static int __ref try_remove_memory(u64 start, u64 size) > > +static void __ref __try_remove_memory

Re: [PATCH v2 2/3] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Mon, 2023-07-24 at 11:16 +0800, Huang, Ying wrote: > "Aneesh Kumar K.V" writes: > > > > > @@ -1339,27 +1367,20 @@ int __ref add_memory_resource(int nid, > > > struct resource *res, mhp_t mhp_flags) > > > /* > > > * Self hosted memmap array > > > */ > > > -   if (m

[PATCH v3 2/2] dax/kmem: allow kmem to add memory with memmap_on_memory

Large amounts of memory managed by the kmem driver may come in via CXL, and it is often desirable to have the memmap for this memory on the new memory itself. Enroll kmem-managed memory for memmap_on_memory semantics as a default. Add a sysfs override under the dax device to opt out of this behavi

[PATCH v3 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks

The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is restricted to 'memblock_size' chunks of memory being added. Adding a larger span of memory precludes memmap_on_memory semantics. For users of hotplug such as kmem, large amounts of memory might get added from the CXL subsystem. In some cases,

[PATCH v3 0/2] mm: use memmap_on_memory semantics for dax/kmem

The dax/kmem driver can potentially hot-add large amounts of memory originating from CXL memory expanders, or NVDIMMs, or other 'device memories'. There is a chance there isn't enough regular system memory available to fit the memmap for this new memory. It's therefore desirable, if all other condi