Messages in this thread | | | Date | Tue, 25 Jul 2023 17:54:17 +0200 | Subject | Re: [PATCH v2 0/3] mm: use memmap_on_memory semantics for dax/kmem | From | David Hildenbrand <> |
| |
On 20.07.23 09:14, Vishal Verma wrote: > 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 conditions are met, for the kmem managed memory > to place its memmap on the newly added memory itself. > > The main hurdle for accomplishing this for kmem is that memmap_on_memory > can only be done if the memory being added is equal to the size of one > memblock. To overcome this,allow the hotplug code to split an add_memory() > request into memblock-sized chunks, and try_remove_memory() to also > expect and handle such a scenario. > > Patch 1 exports mhp_supports_memmap_on_memory() so it can be used by the > kmem driver. > > Patch 2 teaches the memory_hotplug code to allow for splitting > add_memory() and remove_memory() requests over memblock sized chunks. > > Patch 3 adds a sysfs control for the kmem driver that would > allow an opt-out of using memmap_on_memory for the memory being added. >
It might be reasonable to rebase this on Aneesh's work. For example, patch #1 might not be required anymore.
-- Cheers,
David / dhildenb
| |