Re: [PATCH v9 bpf-next 1/9] x86/Kconfig: select HAVE_ARCH_HUGE_VMALLOC with HAVE_ARCH_HUGE_VMAP

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Mon, 2022-03-28 at 23:27 +0000, Song Liu wrote:
> I like this direction. But I am afraid this is not enough. Using
> VM_NO_HUGE_VMAP in module_alloc() will make sure we don't allocate 
> huge pages for modules. But other users of __vmalloc_node_range(), 
> such as vzalloc in Paul's report, may still hit the issue. 
> 
> Maybe we need another flag VM_FORCE_HUGE_VMAP that bypasses 
> vmap_allow_huge check. Something like the diff below.
> 
> Would this work?

Yea, that looks like a safer direction. It's too bad we can't have
automatic large pages, but it doesn't seem ready to just turn on for
the whole x86 kernel.

I'm not sure about this implementation though. It would let large pages
get enabled without HAVE_ARCH_HUGE_VMALLOC and also despite the disable
kernel parameter.

Apparently some architectures can handle large pages automatically and
it has benefits for them, so maybe vmalloc should support both
behaviors based on config. Like there should a
ARCH_HUGE_VMALLOC_REQUIRE_FLAG config. If configured it requires
VM_HUGE_VMAP (or some name). I don't think FORCE fits, because the
current logic would not always give huge pages.

But yea, seems risky to leave it on generally, even if you could fix
Paul's specific issue.