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@xxxxxxxxxx> 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
