[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1598006399.kdw772nr6n.astroid@bobo.none>
Date: Fri, 21 Aug 2020 21:11:19 +1000
From: Nicholas Piggin <npiggin@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
Christophe Leroy <christophe.leroy@...roup.eu>,
linux-mm@...ck.org
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, Zefan Li <lizefan@...wei.com>
Subject: Re: [PATCH v5 0/8] huge vmalloc mappings
Excerpts from Christophe Leroy's message of August 21, 2020 3:47 pm:
>
>
> Le 21/08/2020 à 06:44, Nicholas Piggin a écrit :
>> I made this powerpc-only for the time being. It shouldn't be too hard to
>> add support for other archs that define HUGE_VMAP. I have booted x86
>> with it enabled, just may not have audited everything.
>
> I like this series, but if I understand correctly it enables huge
> vmalloc mappings only for hugepages sizes matching a page directory
> levels, ie on a PPC32 it would work only for 4M hugepages.
Yeah it really just uses the HUGE_VMAP mapping which is already there.
> On the 8xx, we only have 8M and 512k hugepages. Any change that it can
> support these as well one day ?
The vmap_range interface can now handle that, then adding support is the
main work. Either make it weak and arch can override it, or add some
arch helpers to make the generic version create the huge pages if it's
not too ugly. Then you get those large pages for ioremap for free.
The vmalloc part to allocate and try to map a bigger page size and use
it is quite trivial to change from PMD to an arch specific size.
Thanks,
Nick
Powered by blists - more mailing lists