Re: [PATCH V4 1/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_populate_basepages()
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Anshuman Khandual <anshuman.khandual@xxxxxxx>, linux-mm@xxxxxxxxx
- Subject: Re: [PATCH V4 1/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_populate_basepages()
- From: David Hildenbrand <david@xxxxxxxxxx>
- Date: Tue, 7 Jul 2020 09:26:43 +0200
- Cc: justin.he@xxxxxxx, catalin.marinas@xxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, Will Deacon <will@xxxxxxxxxx>, Mark Rutland <mark.rutland@xxxxxxx>, Paul Walmsley <paul.walmsley@xxxxxxxxxx>, Palmer Dabbelt <palmer@xxxxxxxxxxx>, Tony Luck <tony.luck@xxxxxxxxx>, Fenghua Yu <fenghua.yu@xxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, Andy Lutomirski <luto@xxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Mike Rapoport <rppt@xxxxxxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxx>, "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx>, "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>, Dan Williams <dan.j.williams@xxxxxxxxx>, Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-ia64@xxxxxxxxxxxxxxx, linux-riscv@xxxxxxxxxxxxxxxxxxx, x86@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
- In-reply-to: <7ac5ff78-378c-37e2-444f-9f72844b8697@arm.com>
- Organization: Red Hat GmbH
- References: <1594004178-8861-1-git-send-email-anshuman.khandual@arm.com> <1594004178-8861-2-git-send-email-anshuman.khandual@arm.com> <eeeb44f9-bc0a-2c3d-8e8f-7e3d9e066c7e@redhat.com> <7ac5ff78-378c-37e2-444f-9f72844b8697@arm.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
> Hmm, I assume these are some decisions that x86 platform will have to
> make going forward in a subsequent patch as the third patch does for
> the arm64 platform. But it is clearly beyond the scope of this patch
> which never intended to change existing behavior on a given platform.
>
Yeah, I would be curious if my assumption is correct.
>>
>> [...]
>>
>>>
>>> -pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node)
>>> +pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node,
>>> + struct vmem_altmap *altmap)
>>> {
>>> pte_t *pte = pte_offset_kernel(pmd, addr);
>>> if (pte_none(*pte)) {
>>> pte_t entry;
>>> - void *p = vmemmap_alloc_block_buf(PAGE_SIZE, node);
>>> + void *p;
>>> +
>>> + if (altmap)
>>> + p = altmap_alloc_block_buf(PAGE_SIZE, altmap);
>>> + else
>>> + p = vmemmap_alloc_block_buf(PAGE_SIZE, node);
>>> if (!p)
>>> return NULL;
>>
>> I was wondering if
>>
>> if (altmap)
>> p = altmap_alloc_block_buf(PAGE_SIZE, altmap);
>> if (!p)
>> p = vmemmap_alloc_block_buf(PAGE_SIZE, node);
>> if (!p)
>> return NULL
>>
>> Would make sense. But I guess this isn't really relevant in practice,
>> because the altmap is usually sized properly.
>>
>> In general, LGTM.
>
> Okay, I assume that no further changes are required here.
>
Jep,
Reviewed-by: David Hildenbrand <david@xxxxxxxxxx>
--
Thanks,
David / dhildenb
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]