Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp364213ybv; Thu, 13 Feb 2020 01:51:35 -0800 (PST) X-Google-Smtp-Source: APXvYqx5G1o1LcUNKf3625FoGxxS+MS97A7bsluZmyhiCwCyzlm6/hUlTqBqq2WifUlFuJyeyRAP X-Received: by 2002:a9d:674f:: with SMTP id w15mr12636083otm.243.1581587494898; Thu, 13 Feb 2020 01:51:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581587494; cv=none; d=google.com; s=arc-20160816; b=VeoIpuYl7KDY5RKOJsFsD88tWY5UrV8YbV3LH/0wxnS3I6eiEwPkY9zQP6VcervlEs aw61rylnwQqlo0vnpDSzxVtDgeJGZMm51gfCcvXewKCr2qo0O6aTBffEk4TXrAki0U2E +N+Ncs+HM6VhPB27gWDeYUgLplPMhNCVX3Duw8x37wgikJ7o0RoCaseJT8wEmARlTfcL ttlkwzXTkA/bRQzkCnVz2mJovfgyjLPQcrnDsAZtHYuURutiDc0YLz5hd8RFh1c+Nl8X 8Y1v/PeoGSdpDGdV9p7CjT1rk5fjxlncCmkZ9Dq/NorZ93WsK8KjWC08jCxs5QcaslPq t3pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=QaLj1/t8Y299yAANQDpKlbxB1Gyg8uOg1UkCIehjVmc=; b=z3gt+uK0dic8UxonN9Two4QfPG7Z1R+aLlC7ZtEAxE5gBw/y1qHcfigQCUwD5SZ5aj pMPFsv4tf8UTL+JkrdwpvpEkdnWS4QaqDlwk3hr0cHELwO02ib/ngi1Mvw96aNu7H75R qWiJYR6StTerB7aSHs23Mar5h2jv7XCK6A5kaedIHaWpYOL8utltXqgqST1qjAgGX2bL TmFrDjtjfRbXdUqDkQu8LkqgsKtq701ymlXCahLogsAXLZB5r6KOnTdp8xHWaEVXlxJR 9Ce7gi87STWb5sccOngbGmPjKAKpD3LY8l1tmRW1tYYtx3sPNaPD1FSxFKD+AYObJkaF U63g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r22si836773otn.192.2020.02.13.01.51.21; Thu, 13 Feb 2020 01:51:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729675AbgBMJum (ORCPT + 99 others); Thu, 13 Feb 2020 04:50:42 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:38395 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729557AbgBMJul (ORCPT ); Thu, 13 Feb 2020 04:50:41 -0500 Received: from kresse.hi.pengutronix.de ([2001:67c:670:100:1d::2a]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1j2B8i-00040c-JK; Thu, 13 Feb 2020 10:50:32 +0100 Message-ID: <38b3a9d683932ebe9fdb4c8f5100a408b7a9a425.camel@pengutronix.de> Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU From: Lucas Stach To: Russell King - ARM Linux admin , Linus Torvalds Cc: 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 Date: Thu, 13 Feb 2020 10:50:29 +0100 In-Reply-To: <20200212085004.GL25745@shell.armlinux.org.uk> 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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::2a X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mi, 2020-02-12 at 08:50 +0000, 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. > > > > 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. I know of quite a few embedded ARMv7 systems that will need to be supported for at least 10 years from now, with RAM sizes between 1GB and even the full 4GB (well 3.75GB due to MMIO needing some address space). Deprecating highmem would severely cripple our ability to support those platforms with new kernels. Regards, Lucas