RE: [PATCH v2 3/8] x86/mm: Remove "static" from vmap_pages_range()
From: Michael Kelley
Date: Sun Nov 26 2023 - 20:06:14 EST
From: Christoph Hellwig <hch@xxxxxxxxxxxxx> Sent: Wednesday, November 22, 2023 11:32 PM
>
> On Thu, Nov 23, 2023 at 12:24:49AM +0000, Michael Kelley wrote:
> > > I really do not want to expose vmap_pages_range. Please try to come up
> > > with a good way to encapsulate your map at a certain address primitive
> > > and implement it in vmalloc.c.
> >
> > To clarify, is your concern narrowly about vmap_pages_range()
> > specifically?
>
> The prime concern is that it took a lot of effort to make
> vmap_pages_range static and remove all the abuses. I absolutely
> object to undoing that.
OK, so I assume that means a new variant of vmap_pages_range(),
such as one that always sets the page_shift parameter to PAGE_SIZE,
is also disallowed because of the same potential for abuse.
So the only way to map a system memory page to a vmalloc
vaddr is via vmap() or some vmap() variant, which always
creates a new vmalloc area via get_vm_area(). I've done the
perf measurements, and that approach won't work for this use
case. Independent of the alignment requirements, the churn in
creating and removing a lot of vmalloc areas has too much perf
impact. The use case needs to create a single vmalloc area, and
then repeatedly map/unmap a page in that existing area.
I'll have to handle the top-level problem in this patch set in
a completely different way.
Michael