Re: [PATCH 1/4] arch/*: increase lowmem size to avoid highmem use
From: "H. Peter Anvin" <hpa@zytor.com>
Date: 2025-12-21 15:30:30
Also in:
linux-arm-kernel, linux-fsdevel, linux-mm
On December 21, 2025 1:30:15 AM PST, "David Hildenbrand (Red Hat)" [off-list ref] wrote:
On 12/19/25 21:52, Dave Hansen wrote:quoted
On 12/19/25 12:20, Arnd Bergmann wrote:quoted
quoted
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.I agree with that. In particular in areas where there is the chance that we could count the number of people that actually care about that with one hand (in binary ;) ).
So, maximum 31? ;)