On Fri, Oct 30, 2020 at 11:46 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > > > While at it I might have a look at that debug request from Willy in the > > other end of this thread. Any comment on that? > > > > https://lore.kernel.org/r/87k0v7mrrd.fsf@xxxxxxxxxxxxxxxxxxxxxxx > > I do think that it would be nice to have a debug mode, particularly > since over the last few years we've really lost a lot of HIGHMEM > coverage (to the point that I've wondered how worthwhile it really is > to support at all any more - I think it's Arnd who argued that it's > mainly some embedded ARM variants that will want it for the forseeable > future). > > So I'm honestly somewhat torn. I think HIGHMEM is dying, and yes that > argues for "non-HIGHMEM had better have some debug coverage", but at > the same time I think it doesn't even really matter any more. Shifting the testing of highmem code to the actual users of highmem sounds reasonable to me. This means it will get broken more often, but if it doesn't happen all the time, it might serve as a canary: once a bug survives for long enough, we have a good indication that users stopped caring ;-) > At some > point those embedded ARM platforms just aren't even interesting - they > might as well use older kernels if they are the only thing really > arguing for HIGHMEM at all. Agreed, but it does need a little time to get there. My best guess is three to five years from now we can remove it for good, provided a few things happen first: 1. The remaining users of TI Keystone2, NXP i.MX6 Quad(Plus) and Renesas R8A7790/R8A7791/R8A7742/R8A7743 that use the largest memory configuration must have stopped requiring kernel version updates. These were all introduced at the peak of 32-bit Arm embedded systems around 2013, but they have long (15+ year) product life cycles and users pick these because they do promise kernel updates, unlike other SoC families that get stuck on old vendor kernels much earlier. 2. The plan to add a CONFIG_VMSPLIT_4G_4G option on arch/arm/ must work out. We don't have all the code yet, and so far it looks like it's going to be a bit ugly and a bit slow but not nearly as ugly or slow as it was on x86 20 years ago. This would cover Cortex-A7/A15 systems from 2GB to 4GB, which are still fairly common and need to keep using mainline kernels for much longer than the system in point 1. It won't help on Cortex-A9 machines with 2GB, which I hope can migrate CONFIG_VMSPLIT_2G_OPT as a fallback. 3. No new systems with larger memory must appear. I noticed that e.g. the newly introduced Rockchips RV1109 and Allwinner A50/R328/V316 support LP-DDR4 on a dual Cortex-A7, but I hope that nobody will in practice combine a $2 SoC with a $15 memory chip. Most other 32-bit chips use DDR3, which tends to prohibit configurations over 4GB in new designs, with the cheapest ones limited to 512MB (a single 256Mx16 chip) and the high end having already moved on to 64 bit. Regarding 32-bit non-Arm systems, support for the MIPS-based Baikal T1 was merged earlier this year and is used in Russian PC style systems with up to 8GB. There are also some users on 10+ year old 32-bit netbooks or business laptops, both x86 and Apple G4. The longest-lived 32-bit embedded systems with large memory (other than Arm) are probably NXP QorIQ P20xx/P40xx used in military VME bus systems, and low-end embedded systems based on Vortex86. I'm less worried about all of these because upstream kernel support for ppc32 and x86-32 is already bitrotting and they will likely get stuck on the last working kernel before the TI/Renesas/NXP Arm systems do. Arnd
