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 ;) ).
--
Cheers
David
