From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF96BC388F7 for ; Sat, 31 Oct 2020 13:37:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 890412071A for ; Sat, 31 Oct 2020 13:37:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604151440; bh=KsL4BllLtOAiumSXMCBq8rYe7s/DE2jdXN/dD3vutNo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=XKyCByWVaYuZNxnZ5HiUhY4jYM6v2Ft2IYAEmV15rj8FaFW6EUhR8LNN+vbynNHvf pvr1EEiSHYUoTxFYHJDmA7HvojsvFsKK9Edrr6rB4V8diM9JwHqZAnYx/yC1K6DG5N 4UAoAOa5rPlAAG4aenJoGXYZbqKcaC4at4/xdKzA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727461AbgJaNhT (ORCPT ); Sat, 31 Oct 2020 09:37:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:41528 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727437AbgJaNhT (ORCPT ); Sat, 31 Oct 2020 09:37:19 -0400 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5DC1720885; Sat, 31 Oct 2020 13:37:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604151438; bh=KsL4BllLtOAiumSXMCBq8rYe7s/DE2jdXN/dD3vutNo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=RM6gL96UmqjkPB4vFSwKs67HSErS+vAyVlD8S4mG0PHI5hhzZE3leS9Nv9mggOPyX JXfK4y19g8PIIgLubo74FqId8jx+SP7BzrEHKZgRWm3FHX/JgHSLcPcTGK3GXcFWqE hcK5huelhR7bwU7gFe0tIJwmuL8OYH248yBzDLsI= Received: by mail-qt1-f174.google.com with SMTP id f93so6147092qtb.10; Sat, 31 Oct 2020 06:37:18 -0700 (PDT) X-Gm-Message-State: AOAM5307WL85jdEc9Q5dtyWeBRzkunF8iZIYr4xENs5CU7uR5CuMtS2t p4uS7skDel/KXStXf5dkz464qJQf4YfQ+AH59MQ= X-Google-Smtp-Source: ABdhPJy91qWaVGms2GdzKOjDu6QuHL3ODS3nIJ7TUoaG3D14vcIMVYFpi2taO5I7gplDF7nHf39t19dhIbjX1TCVhrs= X-Received: by 2002:ac8:6c25:: with SMTP id k5mr1254491qtu.142.1604151437406; Sat, 31 Oct 2020 06:37:17 -0700 (PDT) MIME-Version: 1.0 References: <20201029221806.189523375@linutronix.de> <87pn50ob0s.fsf@nanos.tec.linutronix.de> <87blgknjcw.fsf@nanos.tec.linutronix.de> <87sg9vl59i.fsf@nanos.tec.linutronix.de> In-Reply-To: From: Arnd Bergmann Date: Sat, 31 Oct 2020 14:37:01 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends To: Linus Torvalds Cc: Thomas Gleixner , LKML , linux-arch , Peter Zijlstra , Paul McKenney , David Airlie , Daniel Vetter , Ard Biesheuvel , Herbert Xu , Christoph Hellwig , Sebastian Andrzej Siewior , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Andrew Morton , Linux-MM , "the arch/x86 maintainers" , Vineet Gupta , "open list:SYNOPSYS ARC ARCHITECTURE" , Russell King , Arnd Bergmann , Linux ARM , Guo Ren , linux-csky@vger.kernel.org, Michal Simek , Thomas Bogendoerfer , "open list:BROADCOM NVRAM DRIVER" , Nick Hu , Greentime Hu , Vincent Chen , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev , "David S. Miller" , linux-sparc , Chris Zankel , Max Filippov , linux-xtensa@linux-xtensa.org, Matthew Wilcox Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Fri, Oct 30, 2020 at 11:46 PM Linus Torvalds wrote: > > On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner 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@nanos.tec.linutronix.de > > 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