All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Arnd Bergmann <arnd@arndb.de>, Arnd Bergmann <arnd@kernel.org>,
	linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Andreas Larsson <andreas@gaisler.com>,
	Christophe Leroy <chleroy@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Matthew Wilcox <willy@infradead.org>,
	Richard Weinberger <richard@nod.at>,
	Russell King <linux@armlinux.org.uk>,
	linux-arm-kernel@lists.infradead.org,
	linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	Michal Simek <monstr@monstr.eu>,
	"David Hildenbrand (Red Hat)" <david@kernel.org>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>, Nishanth Menon <nm@ti.com>,
	Lucas Stach <l.stach@pengutronix.de>
Subject: Re: [PATCH 1/4] arch/*: increase lowmem size to avoid highmem use
Date: Fri, 19 Dec 2025 12:52:21 -0800	[thread overview]
Message-ID: <a2ce2849-e572-404c-9713-9283a43c09fe@intel.com> (raw)
In-Reply-To: <bad18ad8-93e8-4150-a85e-a2852e243363@app.fastmail.com>

On 12/19/25 12:20, Arnd Bergmann wrote:
>> For simplicity, I think this can just be:
>>
>> -	default VMSPLIT_3G
>> +	default VMSPLIT_2G
>>
>> I doubt the 2G vs. 2G_OPT matters in very many cases. If it does, folks
>> can just set it in their config manually.
>>
>> But, in the end, I don't this this matters all that much. If you think
>> having x86 be consistent with ARM, for example, is more important and
>> ARM really wants this complexity, I can live with it.
> Yes, I think we do want the default of VMSPLIT_3G_OPT for
> configs that have neither highmem nor lpae, otherwise the most
> common embedded configs go from 3072 MiB to 1792 MiB of virtual
> addressing, and that is much more likely to cause regressions
> than the 2816 MiB default.
> 
> It would be nice to not need the VMSPLIT_2G default for PAE/LPAE,
> but that seems like a larger change.

The only thing we'd "regress" would be someone who is repeatedly
starting from scratch with a defconfig and expecting defconfig to be the
same all the time. I honestly think that's highly unlikely.

If folks are upgrading and _actually_ exposed to regressions, they've
got an existing config and won't be hit by these defaults at *all*. They
won't actually regress.

In other words, I think we can be a lot more aggressive about defaults
than with the feature set we support. I'd much rather add complexity in
here for solving a real problem, like if we have armies of 32-bit x86
users constantly starting new projects from scratch and using defconfigs.

I'd _really_ like to keep the defaults as simple as possible.


  reply	other threads:[~2025-12-19 20:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-19 16:15 [PATCH 0/4] mm: increase lowmem size in linux-7.0 Arnd Bergmann
2025-12-19 16:15 ` [PATCH 1/4] arch/*: increase lowmem size to avoid highmem use Arnd Bergmann
2025-12-19 18:02   ` Dave Hansen
2025-12-19 20:20     ` Arnd Bergmann
2025-12-19 20:52       ` Dave Hansen [this message]
2025-12-20 12:17         ` Arnd Bergmann
2026-01-06 17:01           ` Dave Hansen
2025-12-21  9:30         ` David Hildenbrand (Red Hat)
2025-12-21 15:26           ` H. Peter Anvin
2025-12-24 11:35   ` Christophe Leroy (CS GROUP)
2026-01-08 14:32     ` Christophe Leroy (CS GROUP)
2025-12-19 16:15 ` [PATCH 2/4] ARM: add CONFIG_VMSPLIT_2G_OPT option Arnd Bergmann
2025-12-19 16:15 ` [PATCH 3/4] ARM: remove support for highmem on VIVT Arnd Bergmann
2025-12-19 17:14   ` Jason Gunthorpe
2025-12-19 20:34     ` Arnd Bergmann
2025-12-24  2:26       ` Jason Gunthorpe
2025-12-24 10:39         ` Arnd Bergmann
2026-01-02 12:12         ` Russell King (Oracle)
2025-12-19 16:15 ` [PATCH 4/4] mm: remove ARCH_NEEDS_KMAP_HIGH_GET Arnd Bergmann

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=a2ce2849-e572-404c-9713-9283a43c09fe@intel.com \
    --to=dave.hansen@intel.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreas@gaisler.com \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=bp@alien8.de \
    --cc=chleroy@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@kernel.org \
    --cc=hpa@zytor.com \
    --cc=jgg@nvidia.com \
    --cc=l.stach@pengutronix.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=maddy@linux.ibm.com \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=monstr@monstr.eu \
    --cc=mpe@ellerman.id.au \
    --cc=nm@ti.com \
    --cc=npiggin@gmail.com \
    --cc=richard@nod.at \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.