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=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 C1D64C2BA83 for ; Thu, 13 Feb 2020 16:53:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 95FAC22314 for ; Thu, 13 Feb 2020 16:53:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728454AbgBMQxK (ORCPT ); Thu, 13 Feb 2020 11:53:10 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:54821 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727705AbgBMQxJ (ORCPT ); Thu, 13 Feb 2020 11:53:09 -0500 Received: from mail-qt1-f181.google.com ([209.85.160.181]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1N5mSj-1jZZ3g2UR9-017H58; Thu, 13 Feb 2020 17:53:07 +0100 Received: by mail-qt1-f181.google.com with SMTP id e21so4841150qtp.13; Thu, 13 Feb 2020 08:53:07 -0800 (PST) X-Gm-Message-State: APjAAAUFnk+9CdLaeCrmBl4EjKOXaaXbZjyONt7haFYOX1zLN4ALW1Cd Z1DvKEIMgTFYq1IvUNVim7uHuFReuo/S4gb9WJk= X-Google-Smtp-Source: APXvYqy4gfD4gDOo3l2kqBaxaneA3Mxd3sL9iK2C79jzJxJBs1MCO7MsBN5MK3tSaslTWwKsP/R7oVEhM2+rnrndMy0= X-Received: by 2002:ac8:669a:: with SMTP id d26mr5640059qtp.304.1581612786288; Thu, 13 Feb 2020 08:53:06 -0800 (PST) MIME-Version: 1.0 References: <20200211175507.178100-1-hannes@cmpxchg.org> <29b6e848ff4ad69b55201751c9880921266ec7f4.camel@surriel.com> <20200211193101.GA178975@cmpxchg.org> <20200211154438.14ef129db412574c5576facf@linux-foundation.org> <20200211164701.4ac88d9222e23d1e8cc57c51@linux-foundation.org> <20200212085004.GL25745@shell.armlinux.org.uk> In-Reply-To: <20200212085004.GL25745@shell.armlinux.org.uk> From: Arnd Bergmann Date: Thu, 13 Feb 2020 17:52:49 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Russell King - ARM Linux admin Cc: Linus Torvalds , Michal Hocko , Rik van Riel , Catalin Marinas , kernel-team@fb.com, Dave Chinner , Linux Kernel Mailing List , Linux-MM , Yafang Shao , Al Viro , Johannes Weiner , linux-fsdevel , Andrew Morton , Roman Gushchin , Linux ARM , Kishon Vijay Abraham I , Santosh Shilimkar Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:EclmwEE9SmZcXxxr7DlYxo3CLjauKnvZQEhwJDlgJsEOcZs6NmZ PuSkreKNIwmWpRbJmtTJ1hQGvP0avOPS8OWgcaEiRrRePx14epwFSa+lOoxxXAqv//USFb4 7fi1956J1PfI0AXNm+W63LHpxRrpFUTb+BVX9o/vMkyTyyAktzeN4fdYXptTbDlZaFkEP2t Tq7+quiINSxLe9j1d1enw== X-UI-Out-Filterresults: notjunk:1;V03:K0:92ve0G3h8N0=:UfJVsMRo1yh19qw5q5p6tb kuxI+/rPBoSnofKN1GNBnSeH7CE/rdPSuh8TZycv8CaWQQlyRy2/PhgahW9gr1KDMKX4zNdMY juXyKuST67nvmnnIBOaFr/gqy+GJW5YXRBZtf+hV23WzkbkT45KvKlvVMVv4BzXcsSzzZmt8Q xIkFvwIZmrqvZLyG3i7f3ojIQ2lJBRsrw0prp9vVmdBN86l44TpqyrWENzhAZr2FM2EaDPWNN euWtb0V6odrDgpBqdoOZz42ahwMKZQ87HEC0pqvob0QKMAO2yj4Xwcw68MV9CUBM+9ZVKTljb T+oOs9sbTWsBjtX/7uunDwBI+eLA+1zDqdvUPbX8tWAwRIvsEfj2n5toOStbIQ7nHmpwc+bGt Eg4ifEphQVeSu3fdrRLCsql2FofpBfpEEsUCbk/LPItzQIAy3yzJ24dR07vKhpoFkrdtegSE1 ylVdCTo3RnxFPuS2HSW4q+BIiUsBflzNY5k1PkAQuDLLeBAo5lN5n+lB8ARBLm2SeFuKfjMbM 7/bOxwIG7YMffOqIR+OGO5WSDKlbnZUpliiPWaHvygzG3eSZFDbSW5LVUV4GS/Bi9t1oRETBx dI2kSBTIGOCck4me2JxIbB5QZPY1aH7jZbNDK+IUcjuKwdszQMrPOkGaQI2/FxcBrFv6tk9fM d8msPbhi3tx3Q7qc0iQweANEy/715ZSKbIJSIq82EtY+MnwIcfFhZCkO6ntyXd5T2x4ThQi0Q w3V2ioWDbUtz01UfOsPd39UJ/y96gPN2dL5KZfSFIZ/Ni53X6DNvhVvVH+3qiw+5HCk9NTZoO VLtaUP8CbD9ipX9KXsVxKgYyUarOY/ib9UmwT/kdlqqWb58wQ8= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin wrote: > > On Tue, Feb 11, 2020 at 05:03:02PM -0800, Linus Torvalds wrote: > > On Tue, Feb 11, 2020 at 4:47 PM Andrew Morton wrote: > > > > > > What's the situation with highmem on ARM? > > > > Afaik it's exactly the same as highmem on x86 - only 32-bit ARM ever > > needed it, and I was ranting at some people for repeating all the > > mistakes Intel did. > > > > But arm64 doesn't need it, and while 32-bit arm is obviosuly still > > selling, I think that in many ways the switch-over to 64-bit has been > > quicker on ARM than it was on x86. Partly because it happened later > > (so all the 64-bit teething pains were dealt with), but largely > > because everybody ended up actively discouraging 32-bit on the Android > > side. > > > > There were a couple of unfortunate early 32-bit arm server attempts, > > but they were - predictably - complete garbage and nobody bought them. > > They don't exist any more. I'd generally agree with that, the systems with more than 4GB tended to be high-end systems predating the Cortex-A53/A57 that quickly got replaced once there were actual 64-bit parts, this would include axm5516 (replaced with x86-64 cores after sale to Intel), hip04 (replaced with arm64), or ecx-2000 (Calxeda bankruptcy). The one 32-bit SoC that I can think of that can actually drive lots of RAM and is still actively marketed is TI Keystone-2/AM5K2. The embedded AM5K2 is listed supporting up to 8GB of RAM, but the verison in the HPE ProLiant m800 server could take up to 32GB (!). I added Santosh and Kishon to Cc, they can probably comment on how long they think users will upgrade kernels on these. I suspect these devices can live for a very long time in things like wireless base stations, but it's possible that they all run on old kernels anyway by now (and are not worried about y2038). > > So at least my gut feel is that the arm people don't have any big > > reason to push for maintaining HIGHMEM support either. > > > > But I'm adding a couple of arm people and the arm list just in case > > they have some input. > > > > [ Obvious background for newly added people: we're talking about > > making CONFIG_HIGHMEM a deprecated feature and saying that if you want > > to run with lots of memory on a 32-bit kernel, you're doing legacy > > stuff and can use a legacy kernel ] > > Well, the recent 32-bit ARM systems generally have more than 1G > of memory, so make use of highmem as a rule. You're probably > talking about crippling support for any 32-bit ARM system produced > in the last 8 to 10 years. What I'm observing in the newly added board support is that memory configurations are actually going down, driven by component cost. 512MB is really cheap (~$4) these days with a single 256Mx16 DDR3 chip or two 128Mx16. Going beyond 1GB is where things get expensive with either 4+ chips or LPDDR3/LPDDR4 memory. For designs with 1GB, we're probably better off just using CONFIG_VMSPLIT_3G_OPT (without LPAE) anyway, completely avoiding highmem. That is particularly true on systems with a custom kernel configuration. 2GB machines are less common, but are definitely important, e.g. MT6580 based Android phones and some industrial embedded machines that will live a long time. I've recently seen reports of odd behavior with CONFIG_VMSPLIT_2G and plus CONFIG_HIGHMEM and a 7:1 ratio of lowmem to highmem that apparently causes OOM despite lots of lowmem being free. I suspect a lot of those workloads would still be better off with a CONFIG_VMSPLIT_2G_OPT (1.75 GB user, 2GB linear map). That config unfortunately has a few problems, too: - nobody has implemented it - it won't work with LPAE and therefore cannot support hardware that relies on high physical addresses for RAM or MMIO (those could run CONFIG_VMSPLIT_2G at the cost of wasting 12.5% of RAM). - any workload that requires the full 3GB of virtual address space won't work at all. This might be e.g. MAP_FIXED users, or build servers linking large binaries. It will take a while to find out what kinds of workloads suffer the most from a different vmsplit and what can be done to address that, but we could start by changing the kernel defconfig and distro builds to see who complains ;-) I think 32-bit ARM machines with 3GB or more are getting very rare, but some still exist: - The Armada XP development board had a DIMM slot that could take large memory (possibly up to 8GB with LPAE). This never shipped as a commercial product, but distro build servers sometimes still run on this, or on the old Calxeda or Keystone server systems. - a few early i.MX6 boards (e.g. HummingBoard) came had 4GB of RAM, though none of these seem to be available any more. - High-end phones from 2013/2014 had 3GB LPDDR3 before getting obsoleted by 64-bit phones. Presumably none of these ever ran Linux-4.x or newer. - My main laptop is a RK3288 based Chromebook with 4GB that just got updated to linux-4.19 by Google. Official updates apparently stop this summer, but it could easily run Debian later on. - Some people run 32-bit kernels on a 64-bit Raspberry Pi 4 or on arm64 KVM with lots of RAM. These should probably all migrate to 64-bit kernels with compat user space anyway. In theory these could also run on a VMSPLIT_4G_4G-like setup, but I don't think anyone wants to go there. Deprecating highmem definitely impacts any such users significantly, though staying on an LTS kernel may be an option if there are only few of them. Arnd 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=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 53FAEC3F68F for ; Thu, 13 Feb 2020 16:53:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 128F5206ED for ; Thu, 13 Feb 2020 16:53:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 128F5206ED Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B1F866B0577; Thu, 13 Feb 2020 11:53:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AF8166B0579; Thu, 13 Feb 2020 11:53:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E6E86B057A; Thu, 13 Feb 2020 11:53:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0235.hostedemail.com [216.40.44.235]) by kanga.kvack.org (Postfix) with ESMTP id 874AF6B0577 for ; Thu, 13 Feb 2020 11:53:10 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 39759181AEF10 for ; Thu, 13 Feb 2020 16:53:10 +0000 (UTC) X-FDA: 76485698940.23.anger52_72e467121c84f X-HE-Tag: anger52_72e467121c84f X-Filterd-Recvd-Size: 9549 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Feb 2020 16:53:09 +0000 (UTC) Received: from mail-qt1-f173.google.com ([209.85.160.173]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1Mf0Je-1jik1Z3Exm-00gbsO for ; Thu, 13 Feb 2020 17:53:07 +0100 Received: by mail-qt1-f173.google.com with SMTP id d5so4906454qto.0 for ; Thu, 13 Feb 2020 08:53:07 -0800 (PST) X-Gm-Message-State: APjAAAWEAIrq6acQ8amdaX1OBRP4sWxMhmiZcFAiD57caIzdw9Guhj1X YBVfY+W4M+fXsn/sXVmztA2RXPTEfPCtLIWY8kM= X-Google-Smtp-Source: APXvYqy4gfD4gDOo3l2kqBaxaneA3Mxd3sL9iK2C79jzJxJBs1MCO7MsBN5MK3tSaslTWwKsP/R7oVEhM2+rnrndMy0= X-Received: by 2002:ac8:669a:: with SMTP id d26mr5640059qtp.304.1581612786288; Thu, 13 Feb 2020 08:53:06 -0800 (PST) MIME-Version: 1.0 References: <20200211175507.178100-1-hannes@cmpxchg.org> <29b6e848ff4ad69b55201751c9880921266ec7f4.camel@surriel.com> <20200211193101.GA178975@cmpxchg.org> <20200211154438.14ef129db412574c5576facf@linux-foundation.org> <20200211164701.4ac88d9222e23d1e8cc57c51@linux-foundation.org> <20200212085004.GL25745@shell.armlinux.org.uk> In-Reply-To: <20200212085004.GL25745@shell.armlinux.org.uk> From: Arnd Bergmann Date: Thu, 13 Feb 2020 17:52:49 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Russell King - ARM Linux admin Cc: Linus Torvalds , Michal Hocko , Rik van Riel , Catalin Marinas , kernel-team@fb.com, Dave Chinner , Linux Kernel Mailing List , Linux-MM , Yafang Shao , Al Viro , Johannes Weiner , linux-fsdevel , Andrew Morton , Roman Gushchin , Linux ARM , Kishon Vijay Abraham I , Santosh Shilimkar Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:K7qZHB4ME3zgcZrdEKh0h8iyMk3W2v3JGP2LObtKLvLs+V//J9d y9epcpMWGtBxtkzD4yhvVKzSHX6R4tGtVp+pEISQYn/asmv3H4xPng78XfoKTG/cGWGu6+9 aC8BhXC0zVPdJAuMGphkVe4jqxOB48D5sFh4ERWNx1xmjWgYffxMJZ5Y8jKaQc7jrgzyhk4 AD0cqEeToMXpaZezeQrpw== X-UI-Out-Filterresults: notjunk:1;V03:K0:pppTXyaaF2s=:d/YBpLWNys8ixfXtpMqEXt pB8T8P09/iGvp89FbeOWUOOIXAu93NPTtgWptkbhWO8V9vX+4K7yaaK8e0ecxWpCr2j3CnK0g uK8EryyZUT30eknWrBpLEz62evh605IgYymrZGSKfdyNq72/J7AuX7+h5x59kQed+VXDh4ht0 bkcSKDe7rjnLfZdNd3wNcwt+3GcPwn7HNcoW6T0S/hUu37VZxJsvuVA4JXj+mZUPfK1h0sMEv ch4z+s7TYKpmKXQxnTaMFgxHygmEB2DhCyMit01BzqmsvpZ9LktaVSLNFS9K3SxEKkU60Hhhi sQXDWOpbTKcP5HrueU3LjvaqvB7SQ9VT0A27/Sewn60fQ8gDz9GEvTSRs5e/EQv91JP5NZ1TZ Nle0ntxC8Tj5RICwycTifc5fkAoH6zO+jbuw1DgO6kW2Lb1N11KwRdI86ttd+YYiY4WCnRfSA lDsYnNqDHVNGOxP0NaR5ouvti/8/HAGUf/s7+gY363xQabA62eKsxwcOchVE/x7q8sCbfeQyV EKoEI7xwSMtikLbZwVFNo5HofShcf6d7dS3RDNXRg7yDR36kJ6/lEknAIuoGOLZOwPxzdeKQ3 cxW3YLIKYL4VtOrChgwhNT+eTLOcInqp5el1PvyHcVtnkKgPwzFSyfVjy967AEAYSdBY8SL/u qBPh7vLA0jvPV10I1d1eUZCvG3977tWOrAaHiisVGmXFDSG7T7Y67V6UtqwJzZKq5DImelfI2 ONauZihzKD/yn/T3LRZydjXeKL2ZNNc8vAxa5Vxuy5JcOGwZy+xsWYN1TvBOOztRNW/lv6Xsv aV3dDfNFbnxh8G68PFJqMIsXbmgphlM4CdrEwsRLmzjLKLzvV8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin wrote: > > On Tue, Feb 11, 2020 at 05:03:02PM -0800, Linus Torvalds wrote: > > On Tue, Feb 11, 2020 at 4:47 PM Andrew Morton wrote: > > > > > > What's the situation with highmem on ARM? > > > > Afaik it's exactly the same as highmem on x86 - only 32-bit ARM ever > > needed it, and I was ranting at some people for repeating all the > > mistakes Intel did. > > > > But arm64 doesn't need it, and while 32-bit arm is obviosuly still > > selling, I think that in many ways the switch-over to 64-bit has been > > quicker on ARM than it was on x86. Partly because it happened later > > (so all the 64-bit teething pains were dealt with), but largely > > because everybody ended up actively discouraging 32-bit on the Android > > side. > > > > There were a couple of unfortunate early 32-bit arm server attempts, > > but they were - predictably - complete garbage and nobody bought them. > > They don't exist any more. I'd generally agree with that, the systems with more than 4GB tended to be high-end systems predating the Cortex-A53/A57 that quickly got replaced once there were actual 64-bit parts, this would include axm5516 (replaced with x86-64 cores after sale to Intel), hip04 (replaced with arm64), or ecx-2000 (Calxeda bankruptcy). The one 32-bit SoC that I can think of that can actually drive lots of RAM and is still actively marketed is TI Keystone-2/AM5K2. The embedded AM5K2 is listed supporting up to 8GB of RAM, but the verison in the HPE ProLiant m800 server could take up to 32GB (!). I added Santosh and Kishon to Cc, they can probably comment on how long they think users will upgrade kernels on these. I suspect these devices can live for a very long time in things like wireless base stations, but it's possible that they all run on old kernels anyway by now (and are not worried about y2038). > > So at least my gut feel is that the arm people don't have any big > > reason to push for maintaining HIGHMEM support either. > > > > But I'm adding a couple of arm people and the arm list just in case > > they have some input. > > > > [ Obvious background for newly added people: we're talking about > > making CONFIG_HIGHMEM a deprecated feature and saying that if you want > > to run with lots of memory on a 32-bit kernel, you're doing legacy > > stuff and can use a legacy kernel ] > > Well, the recent 32-bit ARM systems generally have more than 1G > of memory, so make use of highmem as a rule. You're probably > talking about crippling support for any 32-bit ARM system produced > in the last 8 to 10 years. What I'm observing in the newly added board support is that memory configurations are actually going down, driven by component cost. 512MB is really cheap (~$4) these days with a single 256Mx16 DDR3 chip or two 128Mx16. Going beyond 1GB is where things get expensive with either 4+ chips or LPDDR3/LPDDR4 memory. For designs with 1GB, we're probably better off just using CONFIG_VMSPLIT_3G_OPT (without LPAE) anyway, completely avoiding highmem. That is particularly true on systems with a custom kernel configuration. 2GB machines are less common, but are definitely important, e.g. MT6580 based Android phones and some industrial embedded machines that will live a long time. I've recently seen reports of odd behavior with CONFIG_VMSPLIT_2G and plus CONFIG_HIGHMEM and a 7:1 ratio of lowmem to highmem that apparently causes OOM despite lots of lowmem being free. I suspect a lot of those workloads would still be better off with a CONFIG_VMSPLIT_2G_OPT (1.75 GB user, 2GB linear map). That config unfortunately has a few problems, too: - nobody has implemented it - it won't work with LPAE and therefore cannot support hardware that relies on high physical addresses for RAM or MMIO (those could run CONFIG_VMSPLIT_2G at the cost of wasting 12.5% of RAM). - any workload that requires the full 3GB of virtual address space won't work at all. This might be e.g. MAP_FIXED users, or build servers linking large binaries. It will take a while to find out what kinds of workloads suffer the most from a different vmsplit and what can be done to address that, but we could start by changing the kernel defconfig and distro builds to see who complains ;-) I think 32-bit ARM machines with 3GB or more are getting very rare, but some still exist: - The Armada XP development board had a DIMM slot that could take large memory (possibly up to 8GB with LPAE). This never shipped as a commercial product, but distro build servers sometimes still run on this, or on the old Calxeda or Keystone server systems. - a few early i.MX6 boards (e.g. HummingBoard) came had 4GB of RAM, though none of these seem to be available any more. - High-end phones from 2013/2014 had 3GB LPDDR3 before getting obsoleted by 64-bit phones. Presumably none of these ever ran Linux-4.x or newer. - My main laptop is a RK3288 based Chromebook with 4GB that just got updated to linux-4.19 by Google. Official updates apparently stop this summer, but it could easily run Debian later on. - Some people run 32-bit kernels on a 64-bit Raspberry Pi 4 or on arm64 KVM with lots of RAM. These should probably all migrate to 64-bit kernels with compat user space anyway. In theory these could also run on a VMSPLIT_4G_4G-like setup, but I don't think anyone wants to go there. Deprecating highmem definitely impacts any such users significantly, though staying on an LTS kernel may be an option if there are only few of them. Arnd 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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 3FD75C2BA83 for ; Thu, 13 Feb 2020 16:55:28 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0DF10206ED for ; Thu, 13 Feb 2020 16:55:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RgOiZ6Hh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0DF10206ED Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lkU7psCQ0hbrEr+62r7P4Edjj1fxLq7zfBMsiflpmvI=; b=RgOiZ6HhxHzcxV JWgHKQcFbGX3d3fEYjuKrtB8+QshLQ0rkr9caZd+55uxz6c2oC0+qFIzyLPWu9vHmlta1GciQIPoM dv3DejvRkZ9GNad5Kp3x3LyMOFrhUu3W/WZe2QMmEmigFZuw4kRdKcT32owo/8X70u3rXiHbSXlQz MWoqKWfj/2yIHKpDIUemBec1WpmNHnc9ldrwIsMWFCc4+S0AuXrs4Fg8CRPXfOrwLCj2fic3Aa0xY 3ohGRQx9s2nztMWXqC0nm7rU1d19NyFqZmS8WOndgtI/O3owXx53Oha+Zu6/Kj850bYWHEOL9iYnA 8krWcYOaCN4+r50fL8pQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j2Hlp-0001fA-KL; Thu, 13 Feb 2020 16:55:21 +0000 Received: from mout.kundenserver.de ([212.227.17.13]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j2Hjk-0006pW-V1 for linux-arm-kernel@lists.infradead.org; Thu, 13 Feb 2020 16:53:17 +0000 Received: from mail-qt1-f179.google.com ([209.85.160.179]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1Md6AP-1jbtT623pj-00aFbZ for ; Thu, 13 Feb 2020 17:53:07 +0100 Received: by mail-qt1-f179.google.com with SMTP id l16so213743qtq.1 for ; Thu, 13 Feb 2020 08:53:07 -0800 (PST) X-Gm-Message-State: APjAAAWzvvwM6BbV++eW8i7s4Qg5PAtwAi+64nswQj2Kria1oSoC7N3f A9GBQlHGnzPbcQnQsY6Gu/UMS63SfOwdsIdgeLs= X-Google-Smtp-Source: APXvYqy4gfD4gDOo3l2kqBaxaneA3Mxd3sL9iK2C79jzJxJBs1MCO7MsBN5MK3tSaslTWwKsP/R7oVEhM2+rnrndMy0= X-Received: by 2002:ac8:669a:: with SMTP id d26mr5640059qtp.304.1581612786288; Thu, 13 Feb 2020 08:53:06 -0800 (PST) MIME-Version: 1.0 References: <20200211175507.178100-1-hannes@cmpxchg.org> <29b6e848ff4ad69b55201751c9880921266ec7f4.camel@surriel.com> <20200211193101.GA178975@cmpxchg.org> <20200211154438.14ef129db412574c5576facf@linux-foundation.org> <20200211164701.4ac88d9222e23d1e8cc57c51@linux-foundation.org> <20200212085004.GL25745@shell.armlinux.org.uk> In-Reply-To: <20200212085004.GL25745@shell.armlinux.org.uk> From: Arnd Bergmann Date: Thu, 13 Feb 2020 17:52:49 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Russell King - ARM Linux admin X-Provags-ID: V03:K1:vEuxEcumCEq2E3HOOzzEcjhrf1an5MJuzTcBItVVKEn0UdFfPdh Iu2XaWmpuO/ff60u4i/qooJp38qIM03pWqooGH5YvVvTA+gUXeDFA3YOEjHWI1x8cbFc5bB SXMZmt6y118KmuiD3p8JJSWFQpkV7v/OAh7kUuHdFjZz3xHBi848qkKIaOk2LvEOVpj9q8P gHb5XqVRhMIQiwbdoPCzw== X-UI-Out-Filterresults: notjunk:1;V03:K0:0vSZrpfVrB8=:3dX+jqXY8uRmeavtdYWXY/ 4rjPmmk/c7AUEyzB9vznB9yqMRYABkb2utRarUZz5WUXuBg8kR8eX8fIjpdgpe/NBn/hmKgw/ /F2j8lQH84tIOjYvh8og6Wk3fScnCQ5nA0l+9gdQnfjNzNA+g9TJUro9aZokVEWoA84i3sz0F dRCGN6HRFL4MUma3yXIq2IWOK5EZMemmwY03ct5n+9pG0FXGPAaNDnI9Iw/ttBsW1uYTSoa3F kCOnRy56tMX+HCbr1UoPaWASN0P5bJGi+k+JTgUw84/xIeObV0T3+o1TbedTAM0KliySGnmJQ j1RDwQt5P+DhH3Zh9NKZ86EgGu3QNWZM8F46patJQZiw5LIXyvU1B8HGayevcCXB0WzPprUIp GSEVD8nTUdHd5yzduSocup7JZQM9Z9mrSiJrgdok3QqYzDioBoM4EgJzYlZwJEPGi/tJPMklc 36Y3CidtFybuKi3eN8yYB90jegAuXnz951yiDiRcIR9E/rdpiF9lZff5wPZv89iJGIztTwT07 wlKKzpXzbpoD3Si+1alROoXO9jWRPut3Ge1jF5vPp+eV02cOBzLxoUT0EKMSSgioBm5C8QaWZ ly0JHX661humckudosara7ddxgaGTaOcEGzhWg1R/gyNURb7cDqWFC23+FfCOtTnoQ7TGAsku rgxYWyyhE795tYC/16Dka1Oqfb88aO+MTAFyRu/3pwJ5avNXrjOQGLPPfaUd22MjZv5AkFvgG UQ1cWeFzqRest91yb+f48GCUaDfzXD6UsxHqWMtjVaYX3O+60gw2fDCES1BWdW2dZaCkvU6ih C5B5vxhOXy9vyhhFaNX9pe6MTDyVL5jXcvELt3mQBAgpgMBNgw= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200213_085313_353485_5397F0D8 X-CRM114-Status: GOOD ( 28.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Michal Hocko , Rik van Riel , Catalin Marinas , Santosh Shilimkar , Dave Chinner , Linux Kernel Mailing List , Roman Gushchin , Linux-MM , Yafang Shao , Al Viro , Johannes Weiner , linux-fsdevel , kernel-team@fb.com, Kishon Vijay Abraham I , Linus Torvalds , Andrew Morton , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin wrote: > > On Tue, Feb 11, 2020 at 05:03:02PM -0800, Linus Torvalds wrote: > > On Tue, Feb 11, 2020 at 4:47 PM Andrew Morton wrote: > > > > > > What's the situation with highmem on ARM? > > > > Afaik it's exactly the same as highmem on x86 - only 32-bit ARM ever > > needed it, and I was ranting at some people for repeating all the > > mistakes Intel did. > > > > But arm64 doesn't need it, and while 32-bit arm is obviosuly still > > selling, I think that in many ways the switch-over to 64-bit has been > > quicker on ARM than it was on x86. Partly because it happened later > > (so all the 64-bit teething pains were dealt with), but largely > > because everybody ended up actively discouraging 32-bit on the Android > > side. > > > > There were a couple of unfortunate early 32-bit arm server attempts, > > but they were - predictably - complete garbage and nobody bought them. > > They don't exist any more. I'd generally agree with that, the systems with more than 4GB tended to be high-end systems predating the Cortex-A53/A57 that quickly got replaced once there were actual 64-bit parts, this would include axm5516 (replaced with x86-64 cores after sale to Intel), hip04 (replaced with arm64), or ecx-2000 (Calxeda bankruptcy). The one 32-bit SoC that I can think of that can actually drive lots of RAM and is still actively marketed is TI Keystone-2/AM5K2. The embedded AM5K2 is listed supporting up to 8GB of RAM, but the verison in the HPE ProLiant m800 server could take up to 32GB (!). I added Santosh and Kishon to Cc, they can probably comment on how long they think users will upgrade kernels on these. I suspect these devices can live for a very long time in things like wireless base stations, but it's possible that they all run on old kernels anyway by now (and are not worried about y2038). > > So at least my gut feel is that the arm people don't have any big > > reason to push for maintaining HIGHMEM support either. > > > > But I'm adding a couple of arm people and the arm list just in case > > they have some input. > > > > [ Obvious background for newly added people: we're talking about > > making CONFIG_HIGHMEM a deprecated feature and saying that if you want > > to run with lots of memory on a 32-bit kernel, you're doing legacy > > stuff and can use a legacy kernel ] > > Well, the recent 32-bit ARM systems generally have more than 1G > of memory, so make use of highmem as a rule. You're probably > talking about crippling support for any 32-bit ARM system produced > in the last 8 to 10 years. What I'm observing in the newly added board support is that memory configurations are actually going down, driven by component cost. 512MB is really cheap (~$4) these days with a single 256Mx16 DDR3 chip or two 128Mx16. Going beyond 1GB is where things get expensive with either 4+ chips or LPDDR3/LPDDR4 memory. For designs with 1GB, we're probably better off just using CONFIG_VMSPLIT_3G_OPT (without LPAE) anyway, completely avoiding highmem. That is particularly true on systems with a custom kernel configuration. 2GB machines are less common, but are definitely important, e.g. MT6580 based Android phones and some industrial embedded machines that will live a long time. I've recently seen reports of odd behavior with CONFIG_VMSPLIT_2G and plus CONFIG_HIGHMEM and a 7:1 ratio of lowmem to highmem that apparently causes OOM despite lots of lowmem being free. I suspect a lot of those workloads would still be better off with a CONFIG_VMSPLIT_2G_OPT (1.75 GB user, 2GB linear map). That config unfortunately has a few problems, too: - nobody has implemented it - it won't work with LPAE and therefore cannot support hardware that relies on high physical addresses for RAM or MMIO (those could run CONFIG_VMSPLIT_2G at the cost of wasting 12.5% of RAM). - any workload that requires the full 3GB of virtual address space won't work at all. This might be e.g. MAP_FIXED users, or build servers linking large binaries. It will take a while to find out what kinds of workloads suffer the most from a different vmsplit and what can be done to address that, but we could start by changing the kernel defconfig and distro builds to see who complains ;-) I think 32-bit ARM machines with 3GB or more are getting very rare, but some still exist: - The Armada XP development board had a DIMM slot that could take large memory (possibly up to 8GB with LPAE). This never shipped as a commercial product, but distro build servers sometimes still run on this, or on the old Calxeda or Keystone server systems. - a few early i.MX6 boards (e.g. HummingBoard) came had 4GB of RAM, though none of these seem to be available any more. - High-end phones from 2013/2014 had 3GB LPDDR3 before getting obsoleted by 64-bit phones. Presumably none of these ever ran Linux-4.x or newer. - My main laptop is a RK3288 based Chromebook with 4GB that just got updated to linux-4.19 by Google. Official updates apparently stop this summer, but it could easily run Debian later on. - Some people run 32-bit kernels on a 64-bit Raspberry Pi 4 or on arm64 KVM with lots of RAM. These should probably all migrate to 64-bit kernels with compat user space anyway. In theory these could also run on a VMSPLIT_4G_4G-like setup, but I don't think anyone wants to go there. Deprecating highmem definitely impacts any such users significantly, though staying on an LTS kernel may be an option if there are only few of them. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel