[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1ab3bba4-dc91-4f8-ecd5-b18b17ec6d8@google.com>
Date: Fri, 18 Jun 2021 12:47:13 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Claudio Imbrenda <imbrenda@...ux.ibm.com>
cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
linux-s390@...r.kernel.org, frankja@...ux.ibm.com,
borntraeger@...ibm.com, cohuck@...hat.com, david@...hat.com,
linux-mm@...ck.org, Uladzislau Rezki <urezki@...il.com>,
Nicholas Piggin <npiggin@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Catalin Marinas <catalin.marinas@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH v4 1/2] mm/vmalloc: add vmalloc_no_huge
On Mon, 14 Jun 2021, Claudio Imbrenda wrote:
> Commit 121e6f3258fe3 ("mm/vmalloc: hugepage vmalloc mappings") added
> support for hugepage vmalloc mappings, it also added the flag
> VM_NO_HUGE_VMAP for __vmalloc_node_range to request the allocation to
> be performed with 0-order non-huge pages. This flag is not accessible
> when calling vmalloc, the only option is to call directly
> __vmalloc_node_range, which is not exported.
>
> This means that a module can't vmalloc memory with small pages.
>
> Case in point: KVM on s390x needs to vmalloc a large area, and it needs
> to be mapped with non-huge pages, because of a hardware limitation.
>
> This patch adds the function vmalloc_no_huge, which works like vmalloc,
> but it is guaranteed to always back the mapping using small pages. This
> new function is exported, therefore it is usable by modules.
>
> Signed-off-by: Claudio Imbrenda <imbrenda@...ux.ibm.com>
> Reviewed-by: Uladzislau Rezki (Sony) <urezki@...il.com>
> Acked-by: Nicholas Piggin <npiggin@...il.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Nicholas Piggin <npiggin@...il.com>
> Cc: Uladzislau Rezki (Sony) <urezki@...il.com>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: David Rientjes <rientjes@...gle.com>
> Cc: Christoph Hellwig <hch@...radead.org>
Acked-by: David Rientjes <rientjes@...gle.com>
Powered by blists - more mailing lists