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.
