[PATCH 1/4] arch/*: increase lowmem size to avoid highmem use

[H. Peter Anvin]

On December 21, 2025 1:30:15 AM PST, "David Hildenbrand (Red Hat)" <david at kernel.org> wrote:
>On 12/19/25 21:52, Dave Hansen wrote:
>> 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.
>
>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? ;)