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