Re: [PATCH v3 2/7] mm/hotplug: Allow memmap on memory hotplug request to fallback

[Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>]

On 7/11/23 3:53 PM, David Hildenbrand wrote:
>> -bool mhp_supports_memmap_on_memory(unsigned long size)
>> +static bool mhp_supports_memmap_on_memory(unsigned long size)
>>   {
>>       unsigned long nr_vmemmap_pages = size / PAGE_SIZE;
>>       unsigned long vmemmap_size = nr_vmemmap_pages * sizeof(struct page);
>> @@ -1339,13 +1339,12 @@ int __ref add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)
>>        * Self hosted memmap array
>>        */
>>       if (mhp_flags & MHP_MEMMAP_ON_MEMORY) {
>> -        if (!mhp_supports_memmap_on_memory(size)) {
>> -            ret = -EINVAL;
>> -            goto error;
>> +        if (mhp_supports_memmap_on_memory(size)) {
>> +            mhp_altmap.free = PHYS_PFN(size);
>> +            mhp_altmap.base_pfn = PHYS_PFN(start);
>> +            params.altmap = &mhp_altmap;
>>           }
>> -        mhp_altmap.free = PHYS_PFN(size);
>> -        mhp_altmap.base_pfn = PHYS_PFN(start);
>> -        params.altmap = &mhp_altmap;
>> +        /* fallback to not using altmap  */
>>       }
>>         /* call arch's memory hotadd */
> 
> In general, LGTM, but please extend the documentation of the parameter in memory_hotplug.h, stating that this is just a hint and that the core can decide to no do that.
> 

will update

modified   include/linux/memory_hotplug.h
@@ -97,6 +97,8 @@ typedef int __bitwise mhp_t;
  * To do so, we will use the beginning of the hot-added range to build
  * the page tables for the memmap array that describes the entire range.
  * Only selected architectures support it with SPARSE_VMEMMAP.
+ * This is only a hint, core kernel can decide to not do this based on
+ * different alignment checks.
  */
 #define MHP_MEMMAP_ON_MEMORY   ((__force mhp_t)BIT(1))