Re: [PATCH] mm: add build-time option to set hotplug default type

[David Hildenbrand <david@redhat.com>]

On 20.12.24 16:17, Gregory Price wrote:
> On Fri, Dec 20, 2024 at 03:59:58PM +0100, David Hildenbrand wrote:
>> On 20.12.24 15:45, Gregory Price wrote:
>>> When memory hotplug auto-online is enabled, hotplug memory blocks are
>>> onlined into ZONE_NORMAL by default. The `memhp_default_state` boot
>>> param allows runtime configuration, but no build-time config exists.
>>
>> + you can configure it at runtime.
>>
>>>
>>> Add a build-time configuration option to change default hotplug zone.
>>>
>>> build config:
>>>     MEMHP_DEFAULT_TYPE
>>>
>>> Selections:
>>>     MEMHP_DEFAULT_TYPE_NORMAL  => mhp_default_online_type = "online"
>>>     MEMHP_DEFAULT_TYPE_MOVABLE => mhp_default_online_type = "online_movable"
>>>
>>> When MEMORY_HOTPLUG_DEFAULT_ONLINE is disabled, MEMHP_DEFAULT_TYPE is
>>> set to "offline" to match the current system behavior.
>>>
>>> ZONE_NORMAL still remains the default, because for systems with a large
>>> amount of hotplug memory, defaulting it to ZONE_MOVABLE may result in
>>> portions failing to online if sufficient ZONE_NORMAL memory does not
>>> exist to describe it.
>>>
>>
>> What's the use case?
>>
>> I'm hoping that we can move away from the compile-time option and let user
>> space, who better knows what to do (especially with different kinds of
>> memory having different requirements) configure auto-onlining or online
>> manually (e.g., devdax).
>>
> 
> At Meta we have a fairly complex boot process that goes through multiple
> kernels before we get to a target kernel to run workloads. Each of those> kernels may have health-checks that want to see the memory is online.

Fancy, I'd love to learn some more about that if there is public 
information available somewhere.

> 
> The build switch makes this particular feature consistent for us across
> all those kernels without having to carry the boot parameter. Eventually
> we'd like to move to udev, but it's not feasible for us right now due
> to the state of CXL BIOS/Platform/Drivers - driver-management does not
> work reliable for all platforms and all devices.

I see.

> 
> This gets us where we're going while the rest catch up.

Understood, let me review the patch briefly.

-- 
Cheers,

David / dhildenb