On December 21, 2025 1:30:15 AM PST, "David Hildenbrand (Red Hat)" <[email protected]> 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? ;)
