[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <36616218-1d3a-b18a-8fb8-4fc9eff22780@c-s.fr>
Date: Tue, 14 Apr 2020 14:28:35 +0200
From: Christophe Leroy <christophe.leroy@....fr>
To: Matthew Wilcox <willy@...radead.org>,
Nicholas Piggin <npiggin@...il.com>
Cc: linux-arch@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
Will Deacon <will@...nel.org>, x86@...nel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Catalin Marinas <catalin.marinas@....com>,
Thomas Gleixner <tglx@...utronix.de>,
linuxppc-dev@...ts.ozlabs.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 4/4] mm/vmalloc: Hugepage vmalloc mappings
Le 13/04/2020 à 15:41, Matthew Wilcox a écrit :
> On Mon, Apr 13, 2020 at 10:53:03PM +1000, Nicholas Piggin wrote:
>> +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) {
>
> ... I think you meant 'page_shift == PAGE_SHIFT'
>
> Overall I like this series, although it's a bit biased towards CPUs
> which have page sizes which match PMD/PUD sizes. It doesn't offer the
> possibility of using 64kB page sizes on ARM, for example. But it's a
> step in the right direction.
>
I was going to ask more or less the same question, I would have liked to
use 512kB hugepages on powerpc 8xx.
Even the 8M hugepages (still on the 8xx), can they be used as well,
taking into account that two PGD entries have to point to the same 8M page ?
I sent out a series which tends to make the management of 512k and 8M
pages closer to what Linux expects, in order to use them inside kernel,
for Linear mappings and Kasan mappings for the moment. See
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=164620
It would be nice if we could amplify it a use it for ioremaps and
vmallocs as well.
Christophe
Powered by blists - more mailing lists