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 71D03C10DCE for ; Sun, 8 Mar 2020 10:59:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2E93A206D7 for ; Sun, 8 Mar 2020 10:59:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E93A206D7 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 CAD706B0007; Sun, 8 Mar 2020 06:59:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C5E4B6B0008; Sun, 8 Mar 2020 06:59:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B256A6B000A; Sun, 8 Mar 2020 06:59:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0088.hostedemail.com [216.40.44.88]) by kanga.kvack.org (Postfix) with ESMTP id 9B50C6B0007 for ; Sun, 8 Mar 2020 06:59:13 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 5841240F4 for ; Sun, 8 Mar 2020 10:59:13 +0000 (UTC) X-FDA: 76571898186.16.rice46_16388155acb49 X-HE-Tag: rice46_16388155acb49 X-Filterd-Recvd-Size: 6199 Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Sun, 8 Mar 2020 10:59:12 +0000 (UTC) Received: from mail-qk1-f176.google.com ([209.85.222.176]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.145]) with ESMTPSA (Nemesis) id 1M72wT-1jHDph45HD-008dac for ; Sun, 08 Mar 2020 11:59:11 +0100 Received: by mail-qk1-f176.google.com with SMTP id m2so6614211qka.7 for ; Sun, 08 Mar 2020 03:59:10 -0700 (PDT) X-Gm-Message-State: ANhLgQ1vqmUarWfdNFzMGMlTedDurxukDK1jku29B6HyH9wRFkfcUCM5 iBrHQUZA7XZntEkGvl8CobXxhX329kNFPeQnKH4= X-Google-Smtp-Source: ADFU+vtLZCrqsvoVRLgLjaKncW5qncKt1oeFxxk4ajRHsCJw8gSTZvblgXUZetJgeQGkfwQsqjkOMZPRrTin3JkbS24= X-Received: by 2002:a37:b984:: with SMTP id j126mr10069404qkf.3.1583665149525; Sun, 08 Mar 2020 03:59:09 -0700 (PDT) MIME-Version: 1.0 References: <20200211193101.GA178975@cmpxchg.org> <20200211154438.14ef129db412574c5576facf@linux-foundation.org> <20200211164701.4ac88d9222e23d1e8cc57c51@linux-foundation.org> <20200212085004.GL25745@shell.armlinux.org.uk> <671b05bc-7237-7422-3ece-f1a4a3652c92@oracle.com> <7c4c1459-60d5-24c8-6eb9-da299ead99ea@oracle.com> <20200306203439.peytghdqragjfhdx@kahuna> In-Reply-To: <20200306203439.peytghdqragjfhdx@kahuna> From: Arnd Bergmann Date: Sun, 8 Mar 2020 11:58:52 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Nishanth Menon Cc: Santosh Shilimkar , Tero Kristo , Linux ARM , 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 , Johannes Weiner , linux-fsdevel , kernel-team@fb.com, Kishon Vijay Abraham I , Linus Torvalds , Andrew Morton , Roman Gushchin Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:pf/iqON9xvMJuuQHcdFqqg+HFCv1Qe6VPZ5Bd01+HEpNYk1o0fn cmkuik+hF8JXt4FhbIwMJaIc8C1H+nbSlNKAjKOj3McX+SHie5D54st8in7MKog6ZHWNXq1 RWoXh0trJ33wBK39vPh8WkSmF/Ko7+nbmxV/8o2syeSwOtqLw5M3ay5bqrXvorrCbkEX7Cn yjXOD4EU6YipeIPXyfgJA== X-UI-Out-Filterresults: notjunk:1;V03:K0:nxFCJXznFOU=:riEvxt3YJkMlyn0bQ8CI83 GlKh9+t0OIHe1sExqFwMsEHUjD27iw9c2S7ssK84JhZv2RVbpYNMAtXu7XrdBELFdV5gVaED2 ItBZLOp/z3dbYkQTIkwz9GrgjT/fTz/209rBHEJRpV71wy+ynqHgO5m/kWtIIaTnE2ZTQR5e7 7nZZWBGxQltj2gW5I4BoQBCdB/3gIu27dA83TlEcavLoIW5L1EImYKcZqgVHecJ26DlAiqT3Y EQTNx4mYVWCrhfPGn/JE93mdONSws0ID5clrd1XqpR9VoUWnyoHGmrsFUMSJH/S7t94gWNP54 JF5m/S3FJNsYX9+E5ylsuiJMHCSsssmChI13QYBCxdGeaPpbSqv8IW943HWwIm+wFV6lpSEvj jCw97FWhEBOe7kVL37NquQtDfXoXykNapJ7RiOvdQOISxc/cnyL5w6NfhPv4uDiSmUamfw8lj jdblpf0zF/fiKy2RBBBr2Bh70S32PjljjQbY/kPbq35uhpWoYTMkIB04oMINowZblks0U4MKS WfgFd55204OwClbedqdcUJVLqt4IGEpZsDv74mimuPWySXk+pWXlgxOFqCXTbZ29rFD1nJIKw sTdhCBcCl2LHo83fcC+PFJnGqUegqjHKlSK+XcQVAPhvpQlItvBVnCIg1SXn6uKeto1LRScyW AuT0fqXvm8bScxWJirCAGZDzwiDxHQVhHH0gtGHvzswesbyn7OGk1ApJQGXrl4iA/x56hfG7m Lp2wOeVNUZDqNxB5yGQvcCb3ZIJwX+1nRYFLQIjUDaoN9uompaq6G8DAUrxfR1aHcilOgPqr2 2cyHHrm5ymr1i6DJf5yBf6p6npTALk4BwCaXzKfmxbL6ReUzmc= 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 Fri, Mar 6, 2020 at 9:36 PM Nishanth Menon wrote: > On 13:11-20200226, santosh.shilimkar@oracle.com wrote: > > ~few 1000s still relevant spread between 4G and 8G (confirmed that both > are present, relevant and in use). > > I wish we could sunset, but unfortunately, I am told(and agree) > that we should'nt just leave products (and these are long term > products stuck in critical parts in our world) hanging in the air, and > migrations to newer kernel do still take place periodically (the best > I can talk in public forum at least). Thank you for the clear answer! I agree we should certainly not break any such use cases, and for the 8GB case there is not really a good replacement (using zram/zswap instead of highmem could work for some new workloads, but would be a rather risky change for an upgrade on already deployed systems). I hope it's ok to ask the same question every few years until you are reasonably sure that the users are ready to stop upgrading kernels beyond the following LTS kernel version. We can also do the same thing for the other 32-bit platforms that exceed the maximum amount of lowmem, and document which ones are known. In the meantime, it would seem useful to increase the amount of lowmem that can be used by default, using a combination of some of the changes mentioned earlier - add a VMSPLIT_2G_OPT config option for non-LPAE ARM kernels to handle the common i.MX6 case with 2GB of RAM without highmem - make VMSPLIT_2G_OPT (without LPAE) or VMSPLIT_2G (with LPAE) the default in most ARM defconfig files as well as distros, and disable highmem where possible, to see what breaks. - extend zswap to use all the available high memory for swap space when highmem is disabled. - revisit CONFIG_VMSPLIT_4G_4G for arm32 (and maybe mips32) to see if it can be done, and what the overhead is. This is probably more work than the others combined, but also the most promising as it allows the most user address space and physical ram to be used. Arnd