Re: [RFC PATCH 2/4] mm: Add support for unaccepted memory hotplug

[Pratik R. Sampat]

On 12/11/25 9:00 AM, Kiryl Shutsemau wrote:
> On Tue, Dec 09, 2025 at 03:36:09PM -0600, Pratik R. Sampat wrote:
>>> Agreed, I think Kiryl was hinting at pre-allocated bitmaps as well.
>>>
>>> Since, the overhead to do this upfront is fairly minimal, that should
>>> certainly simplify things and have very little to no meddling with the
>>> original EFI struct.
>>>
>>
>> Taking another look at this suggestion, I think there may be more to it
>> than I previously thought. Parsing e820 tables to know what the range
>> are for allocating the bitmap to cover hotplug may be difficult. For e.g
>>
>> [ 0.000000] efi: mem110: [Unaccepted <snip>]
>> range=[0x0000000100000000-0x000000017fffffff] (2048MB)
>> [ 0.000000] efi: mem111: [Reserved   <snip>]
>> range=[0x000000fd00000000-0x000000ffffffffff] (12288MB)
>>
>> Parsing of the ACPI SRAT seems to be the one that gives us useful ranges
>> to base the upfront bitmap allocation on. e.g.
>> ...
>> [    0.018357] ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0x17fffffff]
>> [    0.018781] ACPI: SRAT: Node 0 PXM 0 [mem 0x180000000-0x2ffffffff]
>> hotplug
>> This is also where max_possible_pfn gets updated to reflect this range.
> 
> Do I understand correctly that EFI memory map doesn't mention hot plug
> range at all, but SRAT does?
> 
> That's a mess. I thought, all hotpluggable range supposed to be declared
> in the memory map.

Not an EFI expert by a long shot, but seems so.
EFI_MEMORY_HOT_PLUGGABLE attribute does exist for hot-removable regions
of memory that must not be used for allocation during the boot context.
However, I am unclear if this in principle is also supposed to span
the entire range or just the cold-plugged regions of memory.

> 
> I wounder if it is what BIOS provides, or is it result of EFI memmap
> cleanup by kernel? I see we are doing bunch of them, like in
> efi_remove_e820_mmio().
> 
>> One potential solution could be to parse the SRAT during unaccepted
>> memory bitmap allocation in the EFI stub. However, this would fragment
>> the implementation by duplicating the SRAT parsing. Alternatively, we
>> could keep the current approach of dynamically allocating the bitmap on
>> hotplug or I could also replace the entire memblock_reserved unaccepted
>> table like Kiryl suggested if we must absolutely avoid changing the
>> unaccepted structure?
> 
> Other possible option would be to accept all memory on hotplug and don't
> touch the bitmap at all. It might be not that bad: it doesn't block boot.
> We can think of a better solution later, if needed.
> 

Absolutely, accepting memory as soon as it's added is easy.
Benchmarking it's effects may be a little tricky since unlike measuring
boot-time in eager vs lazy we may have to find representative workloads
to measure how much overheads accepting memory up-front adds.

Thanks
--Pratik