Re: [PATCH v5 4/7] mm/hotplug: Support memmap_on_memory when memmap is not aligned to pageblocks

[David Hildenbrand <david@redhat.com>]

On 26.07.23 11:57, Aneesh Kumar K V wrote:
> On 7/26/23 2:34 PM, David Hildenbrand wrote:
>>
>>>>>     /*
>>>>> @@ -1310,7 +1400,10 @@ int __ref add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)
>>>>>     {
>>>>>         struct mhp_params params = { .pgprot = pgprot_mhp(PAGE_KERNEL) };
>>>>>         enum memblock_flags memblock_flags = MEMBLOCK_NONE;
>>>>> -    struct vmem_altmap mhp_altmap = {};
>>>>> +    struct vmem_altmap mhp_altmap = {
>>>>> +        .base_pfn =  PHYS_PFN(res->start),
>>>>> +        .end_pfn  =  PHYS_PFN(res->end),
>>>>
>>>> Is it required to set .end_pfn, and if so, shouldn't we also set it to
>>>> base_pfn + memory_block_memmap_on_memory_pages()) ?
>>>>
>>>
>>> We use that in ppc64 for checking altmap boundary condition. As we
>>> discussed earlier, ppc64 due to vmemmap mapping size restrictions can't
>>> always allocate vmemmap pages from altmap area even if requested. We
>>> fallback to regular memory alocation in that case (only used now with
>>> pmem). We use altmap.end_pfn for that boundary check. You can refer to
>>> altmap_cross_boundary() for more details.
>>
>> But even then, setting the end to the end of the resource size is wrong, no? We don't want anybody to allocate beyond base_pfn + memory_block_memmap_on_memory_pages().
>>
> 
> altmap.end is the end pfn of the resource

Oh, thanks for pointing that out. I wonder why the altmap even has to 
care about that ...

-- 
Cheers,

David / dhildenb