Re: [PATCH 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2021/12/27 11:19, Matthew Wilcox wrote:
On Mon, Dec 27, 2021 at 09:44:24AM +0800, Kefeng Wang wrote:
On 2021/12/27 1:36, Christophe Leroy wrote:
Le 26/12/2021 à 09:39, Kefeng Wang a écrit :
Add HUGE_VMALLOC_DEFAULT_ENABLED to let user to choose whether or
not enable huge vmalloc mappings by default, and this could make
more architectures to enable huge vmalloc mappings feature but
don't want to enable it by default.

Add hugevmalloc=on/off parameter to enable or disable this feature
at boot time, nohugevmalloc is still supported and equivalent to
hugevmalloc=off.
Is there a real added value to have the user be able to select that ?

If the architecture supports it, is there any good reason to not use it ?
There are some disadvantages[1],  one of the main concerns is the possible

memory waste, we have backported this feature to our kernel 5.10, but our

downstream in our some scenario(especially in embedded), they don't want

it enabled by default, and others want it, this is why patch1 comes.

Why not just do like PPC and enable it by default ? Why should it be
enabled by default on PPC but disabled by default on ARM64 and X86 ?
The PPC is default enabled, we don't changes this behavior.

Maybe upstream is not care about this, as I said in cover-letter, if
arm64/x86

don't want patch1, we could only just select config to enable it.

Let's wait for more feedback.
We should not have different defaults by architecture.  Either we change
the default for PPC, or x86 & arm should have the same default as PPC.

Ok, since HUGE_VMALLOC_DEFAULT_ENABLED is introduced, we could make it

default y, not only select it on PPC, then the ppc/arm64/x86 have same default value.

And if someone don't want it, they could not enable this config.

Meanwhile hugevmalloc=on/off to make this feature to enable/disable at boot time.

I will add some explanation and resend it, thanks.

.





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux