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=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 0B4F1C2BA83 for ; Thu, 13 Feb 2020 09:50:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D6CC82173E for ; Thu, 13 Feb 2020 09:50:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729713AbgBMJum (ORCPT ); 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 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 2EB35C2BA83 for ; Thu, 13 Feb 2020 09:50:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CFFF720848 for ; Thu, 13 Feb 2020 09:50:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CFFF720848 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 04E866B0528; Thu, 13 Feb 2020 04:50:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F1ABD6B0529; Thu, 13 Feb 2020 04:50:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE1F36B052A; Thu, 13 Feb 2020 04:50:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id BF8B56B0528 for ; Thu, 13 Feb 2020 04:50:44 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5E6F05DE2 for ; Thu, 13 Feb 2020 09:50:44 +0000 (UTC) X-FDA: 76484634408.15.night87_40913f01e9c1e X-HE-Tag: night87_40913f01e9c1e X-Filterd-Recvd-Size: 4335 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [85.220.165.71]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Feb 2020 09:50:43 +0000 (UTC) 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-mm@kvack.org 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 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 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 A3470C2BA83 for ; Thu, 13 Feb 2020 09:51:14 +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 70FC620848 for ; Thu, 13 Feb 2020 09:51:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="IyIy7kJZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 70FC620848 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.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:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oj60Q6RcxeNPz9Ftm6cAFbhR9OKbyjoks7BsmPik5LE=; b=IyIy7kJZQV2eNZ XUPCZcJbf/uw/yNiKFX8nCVBg2Q4+YnxD/FIonuf+UFoXKSRVTh79TEq1V3ko28krUhtJD3hZnnLJ TQbenu4z6tGj0SerEoHRCFT6A9hnG4R7AlaSWbM5ka58q+SvEDXdevlU3174CCUFahNoqujZnd3oR ti6HYiJAv5jGg8A1QMVBvAFAQP1W9SZ2KLs1c9mzivMzJeNa4vG3PuC5gjPStLkvMqvjAdH7igH67 KBnQ04VIviDee2JlyaRdSDweDwahnsbiKp8JGwHcldWBFHgVXqDxrfRq3HJVASMw9vbUUyrMIMJyq FBiIkIgMxvQxuyj5F7Gw==; 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 1j2B9H-0003fK-ND; Thu, 13 Feb 2020 09:51:07 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j2B9E-0003eo-2k for linux-arm-kernel@lists.infradead.org; Thu, 13 Feb 2020 09:51:05 +0000 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 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> User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 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-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200213_015104_129422_AAC4D613 X-CRM114-Status: GOOD ( 19.41 ) 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 , Dave Chinner , Linux Kernel Mailing List , Roman Gushchin , Linux-MM , Yafang Shao , Al Viro , Johannes Weiner , linux-fsdevel , kernel-team@fb.com, 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel