Re: CXL Boot to Bash - Section 3: Memory (block) Hotplug

[David Hildenbrand <david@redhat.com>]

On 18.02.25 19:04, Gregory Price wrote:
> On Tue, Feb 18, 2025 at 09:49:28AM -0800, Yang Shi wrote:
>> On Mon, Feb 17, 2025 at 12:05 PM Gregory Price <gourry@gourry.net> wrote:
>>> The node ID passed in as an argument is a "preferred node", which means
>>> is insufficient space on that node exists to service the GFP_KERNEL
>>> allocation, it will fall back to another node.
>>>
>>> If all hot-plugged memory is added to ZONE_MOVABLE, two things occur:
>>>
>>>    1) A portion of the memory block is carved out for to allocate memmap
>>>       data (reducing usable size by 64b*nr_pages)
>>>
>>>    2) The memory is allocated on ZONE_NORMAL on another node..
>>
>> Nice write-up, thanks for putting everything together. A follow up
>> question on this. Do you mean the memmap memory will show up as a new
>> node with ZONE_NORMAL only besides other hot-plugged memory blocks? So
>> we will actually see two nodes are hot-plugged?
>>
> 
> No, it creates 1 ZONE_MOVABLE memory block of size
> 
>                     (BLOCK_SIZE - memmap_size)
> 
> and as far as i can tell the actual memory map allocations still
> occur on ZONE_NORMAL (i.e. not CXL).
> 
> So you just lose the capacity, it's just stranded and unused.

Hm?

If you enable memmap_on_memory, we will place the memmap on that 
carved-out region, independent of ZONE_NORMAL/ZONE_MOVABLE etc. It's the 
"altmap".

Reason that we can place the memmap on a ZONE_MOVABLE is because, 
although it is "unmovable", we told memory offlining code that it 
doesn't have to care about offlining that memmap carveout, there is no 
migration to be done. Just offline the block (memmap gets stale) and 
remove that block (memmap gets removed).

If there is a reason where we carve out the memmap and *not* use it, 
that case must be fixed.

-- 
Cheers,

David / dhildenb