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,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 CC461C2BA83 for ; Sat, 15 Feb 2020 11:25:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 905332067D for ; Sat, 15 Feb 2020 11:25:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726212AbgBOLZq (ORCPT ); Sat, 15 Feb 2020 06:25:46 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:38998 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725965AbgBOLZq (ORCPT ); Sat, 15 Feb 2020 06:25:46 -0500 Received: by mail-oi1-f193.google.com with SMTP id z2so12204351oih.6; Sat, 15 Feb 2020 03:25:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CKm2jdZv4bkhryatSR3sc3YwYWDYL0cZxrSHpiKACgs=; b=NLcrr5QVsMEVPqJg6FgpymJfHkdV0lZW6U1GaDtdFQNaRJfBqmpcFqp7kbR143gh/5 8+I3Z8ivwr++u1Jcn6Kn1fsyt6fyXt/e9a71KB7CMeF3bnS3HpiygFTaisvCh8fE1sOK 867bVWXmFp05ad2hzMTuQFTQ6bRXbw0GgawXPiIuafh8mXtJSC+RtDZYWwTjbtKoByNt zMf1OxxCQBwIMpm7te2kuv9wY9qpzv9vrrAB7G+8NKitRXqF2aTMomy+5B/SgMWMbrRC y68H+MMhcDG+81Tl0aE9/U2hYMy861HUjNFDiqjAMeAfNv/kcj13Ml9sOhnr1fC74VEW EOEA== X-Gm-Message-State: APjAAAWLI/NDnMr0iolXo3/towK6trG0Q1X/q7NCFyjhIb2icu1sa2KF MfTsPRjelu/8q0cWcoml3l8QDY81ns+w5R2r6ew= X-Google-Smtp-Source: APXvYqy3gnViweSJe92lN+8veoys3VonFUwyBJ4mtKyOR9rGe/2O0TS+YkWKNVujqCTFiuI2W++F7LZyFkYUCfJWVbU= X-Received: by 2002:a54:4707:: with SMTP id k7mr4492798oik.153.1581765944894; Sat, 15 Feb 2020 03:25:44 -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: From: Geert Uytterhoeven Date: Sat, 15 Feb 2020 12:25:32 +0100 Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Arnd Bergmann Cc: Russell King - ARM Linux admin , 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 , Chris Paterson , cip-dev@lists.cip-project.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann wrote: > 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: > > > 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. The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split (even for 1 GiB or 2 GiB configurations) in two parts, one below and one above the 32-bit physical limit. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds 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,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 922EAC7114D for ; Sat, 15 Feb 2020 11:25:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 364392067D for ; Sat, 15 Feb 2020 11:25:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 364392067D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AA9736B0005; Sat, 15 Feb 2020 06:25:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A330E6B0006; Sat, 15 Feb 2020 06:25:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F9A86B0007; Sat, 15 Feb 2020 06:25:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0065.hostedemail.com [216.40.44.65]) by kanga.kvack.org (Postfix) with ESMTP id 71BC26B0005 for ; Sat, 15 Feb 2020 06:25:46 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3C044125C for ; Sat, 15 Feb 2020 11:25:46 +0000 (UTC) X-FDA: 76492131492.03.elbow13_89a3981e3aa0e X-HE-Tag: elbow13_89a3981e3aa0e X-Filterd-Recvd-Size: 7819 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Sat, 15 Feb 2020 11:25:45 +0000 (UTC) Received: by mail-oi1-f194.google.com with SMTP id q81so12243141oig.0 for ; Sat, 15 Feb 2020 03:25:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CKm2jdZv4bkhryatSR3sc3YwYWDYL0cZxrSHpiKACgs=; b=o9zqas/W7cvBjhL9aQoBZffk4Glth2dYbcjp+S6BVOslsMWwhslDXLcUUq9E/G3L9M BEo5hrB+KbLWlOWGfiWrKkpuPo/HRhRsNifB0cHOFcmgTNx3uzMSPI87BtUxf7DxWoTd kLvb/jXRUmp4ztNjQ5OK4Icll1KPsE/iVN1YawqAGGIfp6oIaGmTDvYtGQgd6fC7RDc+ FiFkq0co7Fak8/dVh0qmv0aiPV/9W5mgAV9ltOefQt0VJhukjPkwVdfZO0GnW5j8DJAQ 1TkaAje3vYKOvluKu8JlgQaiTOgFvRBMTIo0r8m+cQqjycMSA+6FQpt+wGu1/16IW6OZ NSJw== X-Gm-Message-State: APjAAAWKmLObsbOLN3I4WfI/L3xYDK2XjV+CIZset6EqeTu/CqMZqu6u abch2jgw5g7DWCb3SXTRNKjlbjw3mkXbs6WKqxc= X-Google-Smtp-Source: APXvYqy3gnViweSJe92lN+8veoys3VonFUwyBJ4mtKyOR9rGe/2O0TS+YkWKNVujqCTFiuI2W++F7LZyFkYUCfJWVbU= X-Received: by 2002:a54:4707:: with SMTP id k7mr4492798oik.153.1581765944894; Sat, 15 Feb 2020 03:25:44 -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: From: Geert Uytterhoeven Date: Sat, 15 Feb 2020 12:25:32 +0100 Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Arnd Bergmann Cc: Russell King - ARM Linux admin , 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 , Chris Paterson , cip-dev@lists.cip-project.org Content-Type: text/plain; charset="UTF-8" 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: Hi Arnd, On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann wrote: > 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: > > > 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. The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split (even for 1 GiB or 2 GiB configurations) in two parts, one below and one above the 32-bit physical limit. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds 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,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 EDA26C4741C for ; Sat, 15 Feb 2020 11:26:05 +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 BAC222067D for ; Sat, 15 Feb 2020 11:26:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ciUaLpK9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BAC222067D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org 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=iuMLxJJlw9R707dAZh1la9tOWuSteQZHKnHk9ntNeSM=; b=ciUaLpK9l/bVgg /x9sLnjq8RGNzcgV/MVHotQgBv7o4h6581ClZr0Ch5aFTEZhIL6fxs0V0wWLtOHtlGhZ1qq0XoSP0 My+LTIlokWGtoxPdgIXuhdvQCT3PDQsTiy/RsvSNYYodp7W2WR2xT/KyPzAEki/P2lfH+fXmJ47HX vvoYsE4gEBoK+MQcLIshP9ik0fXj0Bb3DaThwWl35QfoEqFSUIm36GsarEYk/fuH1cNwOQ5cExLtu WM5t6xjIuZ+pG3UbkT4uyN3Ej92zo5TlmO7a/sgHeOu85GCH6zHuOHetHGnJGN2VSGhkEVV1/iytk bzpGeGSfiTf2o2MbibcA==; 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 1j2va4-0004B1-59; Sat, 15 Feb 2020 11:25:52 +0000 Received: from mail-oi1-f194.google.com ([209.85.167.194]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j2va0-0004AF-VS for linux-arm-kernel@lists.infradead.org; Sat, 15 Feb 2020 11:25:50 +0000 Received: by mail-oi1-f194.google.com with SMTP id a22so12172027oid.13 for ; Sat, 15 Feb 2020 03:25:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CKm2jdZv4bkhryatSR3sc3YwYWDYL0cZxrSHpiKACgs=; b=D4zyisUGzRmzBe5I2KU5x7qU/oHfjLkp0aDL/Ob91Q1d53aPT2XKVkdUuGYjUhWKtX 1A4GVNnbfY2d6058YbHqnsjx63p/MgBmu3DmI2RxEKpEtbWwY7s8ajSWFrwAjHVLa1Z4 /b25/uI+fxwX4ppown9SWKjVJz0yM/EgjMspBlkM+WT+y5Zf0XaKDnf1BFwIYCnYrUpK wHxhKm8UcUU1hW/HfrngXWkGxxOblfeZzdkSQpjdaQDh4JMn8NieDFax8apoeelguvib WhTdrpb75AiyDUSjknH+XkIPIMgp7BE2t5eh/IFLM7AadouILdSTgYsoejtULCgzB3kh 4cjw== X-Gm-Message-State: APjAAAVYBfoTeZuaPGIOvc/dhHRzrWE7qXNlpKQBI9wjQ8943XZxoM2I vMAPT5Y+21ZWc5cyfEWzEy+Ikynnym9ceznYys0atg== X-Google-Smtp-Source: APXvYqy3gnViweSJe92lN+8veoys3VonFUwyBJ4mtKyOR9rGe/2O0TS+YkWKNVujqCTFiuI2W++F7LZyFkYUCfJWVbU= X-Received: by 2002:a54:4707:: with SMTP id k7mr4492798oik.153.1581765944894; Sat, 15 Feb 2020 03:25:44 -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: From: Geert Uytterhoeven Date: Sat, 15 Feb 2020 12:25:32 +0100 Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Arnd Bergmann X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200215_032549_014703_8D5022C6 X-CRM114-Status: GOOD ( 30.21 ) 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: Linux ARM , Chris Paterson , Michal Hocko , Rik van Riel , Catalin Marinas , Santosh Shilimkar , Dave Chinner , Russell King - ARM Linux admin , Linux Kernel Mailing List , Linux-MM , Yafang Shao , Al Viro , cip-dev@lists.cip-project.org, Johannes Weiner , linux-fsdevel , kernel-team@fb.com, Kishon Vijay Abraham I , Linus Torvalds , Andrew Morton , Roman Gushchin 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 Hi Arnd, On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann wrote: > 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: > > > 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. The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split (even for 1 GiB or 2 GiB configurations) in two parts, one below and one above the 32-bit physical limit. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: geert@linux-m68k.org (Geert Uytterhoeven) Date: Sat, 15 Feb 2020 12:25:32 +0100 Subject: [cip-dev] [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU In-Reply-To: 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> Message-ID: To: cip-dev@lists.cip-project.org List-Id: cip-dev.lists.cip-project.org Hi Arnd, On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann wrote: > 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: > > > 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. The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split (even for 1 GiB or 2 GiB configurations) in two parts, one below and one above the 32-bit physical limit. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds