Re: [PATCH] arm64/mm: don't WARN when alloc/free-ing device private pages

[John Hubbard]

On 4/6/23 00:31, Ard Biesheuvel wrote:
> Hello John,
> 
> On Thu, 6 Apr 2023 at 06:05, John Hubbard <jhubbard@xxxxxxxxxx> wrote:
>>
>> Although CONFIG_DEVICE_PRIVATE and hmm_range_fault() and related
>> functionality was first developed on x86, it also works on arm64.
>> However, when trying this out on an arm64 system, it turns out that
>> there is a massive slowdown during the setup and teardown phases.
>>
>> This slowdown is due to lots of calls to WARN_ON()'s that are checking
>> for pages that are out of the physical range for the CPU. However,
>> that's a design feature of device private pages: they are specfically
>> chosen in order to be outside of the range of the CPU's true physical
>> pages.
>>

Hi Ard,

Thank you for looking at this so soon, I've been working on filling
in some details and studying what you said.

By the way, to address an implicit question from Andrew on the other
thread, the reason that this slows things down is due to a loop in 
__add_pages() that repeatedly calls through to vmemmap_populate(),
like this:

device driver setup: allocate struct pages for the device (GPU)
    memremap_pages(pagemap.type = MEMORY_DEVICE_PRIVATE)
        pagemap_range()
        __add_pages() /* device private case does this */
            for (; pfn < end_pfn; pfn += cur_nr_pages) {
		/* this loops 125 times on an x86 test machine: */
                sparse_add_section()
                    section_activate()
                        populate_section_memmap()
                            __populate_section_memmap()
                                vmemmap_populate()

> 
> Currently, the vmemmap region is dimensioned to only cover the PFN
> range that backs the linear map. So the WARN() seems appropriate here:
> you are mapping struct page[] ranges outside of the allocated window,
> and afaict, you might actually wrap around and corrupt the linear map
> at the start of the kernel VA space like this.
> 

Well...it's only doing a partial hotplug of these pages, just enough to get
ZONE_DEVICE to work. As I understand it so far, only the struct pages
themselves are ever accessed, not any mappings.

More below:

...
>>                 /* arch/x86/mm/init_64.c */
>>                 vmemmap_free()
>>                 {
>>                   VM_BUG_ON(!PAGE_ALIGNED(start));
>>                   VM_BUG_ON(!PAGE_ALIGNED(end));
>>                   ...
>>                 }
>>
>> So, the warning is a false positive for this case. Therefore, skip the
>> warning if CONFIG_DEVICE_PRIVATE is set.
>>
> 
> I don't think this is a false positive. We'll need to adjust
> VMEMMAP_SIZE to account for this.
> 

Looking at the (new to me) arm64 code for this, VMEMMAP_SIZE is only
ever used to calculate VMEMMAP_END, which in turn is used for the
WARN_ON()'s in question, plus as the "ceiling" arg to free_empty_tables().

It seems Mostly Harmless. How would you feel about changing it to a
WARN_ON_ONCE() as Andrew suggested? That would completely fix the
user-visible symptoms:

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 6f9d8898a025..82d4205af9f2 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1157,7 +1157,7 @@ int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node,
 int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
 		struct vmem_altmap *altmap)
 {
-	WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END));
+	WARN_ON_ONCE((start < VMEMMAP_START) || (end > VMEMMAP_END));
 
 	if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES))
 		return vmemmap_populate_basepages(start, end, node, altmap);
@@ -1169,7 +1169,7 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
 void vmemmap_free(unsigned long start, unsigned long end,
 		struct vmem_altmap *altmap)
 {
-	WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END));
+	WARN_ON_ONCE((start < VMEMMAP_START) || (end > VMEMMAP_END));
 
 	unmap_hotplug_range(start, end, true, altmap);
 	free_empty_tables(start, end, VMEMMAP_START, VMEMMAP_END);



thanks,
-- 
John Hubbard
NVIDIA