linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	"Ingo Molnar" <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Paul Mackerras <paulus@samba.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
Date: Mon, 27 Dec 2021 09:44:24 +0800	[thread overview]
Message-ID: <c7037a3a-d0b1-6351-5e31-22be0d8e0e01@huawei.com> (raw)
In-Reply-To: <6c4bd989-268e-5899-09a7-ac573bd8b4d9@csgroup.eu>


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.

Thanks.

[1] 
https://lore.kernel.org/linux-mm/1616036421.amjz2efujj.astroid@bobo.none/



  reply	other threads:[~2021-12-27  1:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-26  8:39 [PATCH 0/3] mm: support huge vmalloc mapping on arm64/x86 Kefeng Wang
2021-12-26  8:39 ` [PATCH 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior Kefeng Wang
2021-12-26  8:33   ` Kefeng Wang
2021-12-26 17:36   ` Christophe Leroy
2021-12-27  1:44     ` Kefeng Wang [this message]
2021-12-27  3:19       ` Matthew Wilcox
2021-12-27  6:14         ` Kefeng Wang
2021-12-26  8:39 ` [PATCH 2/3] arm64: Support huge vmalloc mappings Kefeng Wang
2021-12-26  8:39 ` [PATCH 3/3] x86: " Kefeng Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c7037a3a-d0b1-6351-5e31-22be0d8e0e01@huawei.com \
    --to=wangkefeng.wang@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox