[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1595213278.m30kayfsvu.astroid@bobo.none>
Date: Mon, 20 Jul 2020 12:49:02 +1000
From: Nicholas Piggin <npiggin@...il.com>
To: linux-mm@...ck.org, Zefan Li <lizefan@...wei.com>
Cc: Borislav
Petkov <bp@...en8.de>,
Catalin Marinas <catalin.marinas@....com>,
"H. Peter Anvin" <hpa@...or.com>, linux-arch@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, Ingo Molnar <mingo@...hat.com>,
Thomas
Gleixner <tglx@...utronix.de>,
Will Deacon <will@...nel.org>, x86@...nel.org
Subject: Re: [PATCH v2 4/4] mm/vmalloc: Hugepage vmalloc mappings
Excerpts from Zefan Li's message of July 20, 2020 12:02 pm:
>> +static int vmap_pages_range_noflush(unsigned long start, unsigned long end,
>> + pgprot_t prot, struct page **pages,
>> + unsigned int page_shift)
>> +{
>> + if (page_shift == PAGE_SIZE) {
>
> Is this a typo of PAGE_SHIFT?
Oh good catch, yeah that'll always be going via the one-at-a-time route
and slow down the small page vmaps. Will fix.
Thanks,
Nick
>
>> + return vmap_small_pages_range_noflush(start, end, prot, pages);
>> + } else {
>> + unsigned long addr = start;
>> + unsigned int i, nr = (end - start) >> page_shift;
>> +
>> + for (i = 0; i < nr; i++) {
>> + int err;
>> +
>> + err = vmap_range_noflush(addr,
>> + addr + (1UL << page_shift),
>> + __pa(page_address(pages[i])), prot,
>> + page_shift);
>> + if (err)
>> + return err;
>> +
>> + addr += 1UL << page_shift;
>> + }
>> +
>> + return 0;
>> + }
>> +}
>> +
>
Powered by blists - more mailing lists