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 32E68C18E5A for ; Mon, 9 Mar 2020 13:33:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EB0F622B48 for ; Mon, 9 Mar 2020 13:33:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB0F622B48 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 98AAB6B0003; Mon, 9 Mar 2020 09:33:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93CC16B0006; Mon, 9 Mar 2020 09:33:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8041F6B0007; Mon, 9 Mar 2020 09:33:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0221.hostedemail.com [216.40.44.221]) by kanga.kvack.org (Postfix) with ESMTP id 652236B0003 for ; Mon, 9 Mar 2020 09:33:47 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 18A8E180AD80F for ; Mon, 9 Mar 2020 13:33:47 +0000 (UTC) X-FDA: 76575916494.14.cream67_783fd103d6925 X-HE-Tag: cream67_783fd103d6925 X-Filterd-Recvd-Size: 6661 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Mar 2020 13:33:46 +0000 (UTC) Received: from mail-qv1-f49.google.com ([209.85.219.49]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MwgOK-1jZ2iQ2x46-00yAhW for ; Mon, 09 Mar 2020 14:33:44 +0100 Received: by mail-qv1-f49.google.com with SMTP id m2so4309428qvu.13 for ; Mon, 09 Mar 2020 06:33:44 -0700 (PDT) X-Gm-Message-State: ANhLgQ2Ssf7jNrS8hvC7EsmTHVv03XrlEZwtn0mpgRQzspSvQnbpOUrz cGZhZND3l9dKvU9AuuyCPTjhCVQU5EH0O0oJNic= X-Google-Smtp-Source: ADFU+vsS4g4CC/jX/g0SgAYUCTcdMUWjdRoIcEGypTKOhZlhcLLVL+lmJ8nsucH78bEHlCzzMXlxQq29RStvENsZj44= X-Received: by 2002:a0c:f647:: with SMTP id s7mr14720813qvm.4.1583760823316; Mon, 09 Mar 2020 06:33:43 -0700 (PDT) MIME-Version: 1.0 References: <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> <20200308141923.GI25745@shell.armlinux.org.uk> In-Reply-To: <20200308141923.GI25745@shell.armlinux.org.uk> From: Arnd Bergmann Date: Mon, 9 Mar 2020 14:33:26 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Russell King - ARM Linux admin Cc: Nishanth Menon , Santosh Shilimkar , Tero Kristo , Linux ARM , Michal Hocko , Rik van Riel , Catalin Marinas , Santosh Shilimkar , Dave Chinner , 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:0s3w5KAHAHJBz+aJR6NNT1CNCxEI1FSkLTE/kzqS/pwoSQkKyHT ScOoyxnw1AFAw+BvlbUtopax25FZdOfZQ2o+7oGv+vfH/3CYBlKMCfaUqHDB7Fq7Z4awRfd mynLP8BMe/dxFrVaefjvZjQYr7666SOLZoJ0Nz0fTxDUEvccqxwiJvfM6u032XlcbRX9qqk YB/zIlKnjErC1yCHEmcig== X-UI-Out-Filterresults: notjunk:1;V03:K0:xH8VpH5zyKU=:CE4lvjq5LQlyu9uS6QjI4b QtQI0+xK30h/sQ1brOD+SbyO3XVE3N0z5K/WThB0FKS91vh6fP14bqPlVujr+2LbNXWkh5Y+i AwHbGH0dhg5kyDDmyyYLxujpU1CIO4zW79PRF0EqnQWFWB5QpKmW+S4YZGpOTM0QCUwYP6A9n DN8ig33cv5KgNwUeSujHwv3j8vNgrNDwbc+SvB/FVVNLiMzbFyJPp4q4ii76vtb5WkDtpijrB Bv5Ok1gPTYC3+FpaXpHEfLLNhPx8mUBA4TJq8qCZFARgMhv6uM0tX/6Ge2+O6Nu+uDU5MVMaw qF4GpCHRg3LaZSHJYUyuGwh2+IKdUI7SJvFrww9+5reeVAy8bd7QUOE5EhuI13XtlXAmyPvCj t/N6Rz6pmDbdowuNjkqbUmgAkRk8DxZb0nha4bX3bqJ9edEUBcI4OCu9EAbfmjKtzxAxdU1qv Z0Y8xbXsY6U6dx+494kX3lx/Xg2wkde2B0JYdmn/S9J1/4fA+h+I5N2PVv3W0jlBfUdxGzgJC s6D7iBKh2Wy4a4b9rKIjnDvFp8q0h6Vs/rAh1heMYkyl7mru83m/cnfOwK7GWrf1y1z6W0H6c QRf0DebQEKcAXyFpC7Pwtd2D+XlIIKg7JxckfHfefgEUoROjrvWLD766OoY8FwEc0ik+3LzU5 Wl/VyVwOO8Gu89/sMjIwXEKDtylZoFV6EfXYG23fN/dbGgpt8B/24DAlhOkhL0phoK/g7YyXK kfh2jhCX7bZz4NhmeeM8HZiJPq8VhC+gVumYU4zScOxFth7zQuCjKUGJN4INaNYybPr5pdrPw 8OLz/3+RU5Pt5Gcl1B361A+7EZy7jZlQUb5n0rzeb9R3uDVe4I= 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 Sun, Mar 8, 2020 at 3:20 PM Russell King - ARM Linux admin wrote: > On Sun, Mar 08, 2020 at 11:58:52AM +0100, Arnd Bergmann wrote: > > On Fri, Mar 6, 2020 at 9:36 PM Nishanth Menon wrote: > > > On 13:11-20200226, santosh.shilimkar@oracle.com wrote: > > > - extend zswap to use all the available high memory for swap space > > when highmem is disabled. > > I don't think that's a good idea. Running debian stable kernels on my > 8GB laptop, I have problems when leaving firefox running long before > even half the 16GB of swap gets consumed - the entire machine slows > down very quickly when it starts swapping more than about 2 or so GB. > It seems either the kernel has become quite bad at selecting pages to > evict. > > It gets to the point where any git operation has a battle to fight > for RAM, despite not touching anything else other than git. > > The behaviour is much like firefox is locking memory into core, but > that doesn't seem to be what's actually going on. I've never really > got to the bottom of it though. > > This is with 64-bit kernel and userspace. I agree there is something going wrong on your machine, but I don't really see how that relates to my suggestion. > So, I'd suggest that trading off RAM available through highmem for VM > space available through zswap is likely a bad idea if you have a > workload that requires 4GB of RAM on a 32-bit machine. Aside from every workload being different, I was thinking of these general observations: - If we are looking at a future without highmem, then it's better to use the extra memory for something than not using it. zswap seems like a reasonable use. - A lot of embedded systems are configured to have no swap at all, which can be for good or not-so-good reasons. Having some swap space available often improves things, even if it comes out of RAM. - A particularly important case to optimize for is 2GB of RAM with LPAE enabled. With CONFIG_VMSPLIT_2G and highmem, this leads to the paradox -ENOMEM when 256MB of highmem are full while plenty of lowmem is available. With highmem disabled, you avoid that at the cost of losing 12% of RAM. - With 4GB+ of RAM and CONFIG_VMSPLIT_2G or CONFIG_VMSPLIT_3G, using gigabytes of RAM for swap space would usually be worse than highmem, but once we have VMSPLIT_4G_4G, it's the same situation as above with 6% of RAM used for zswap instead of highmem. Arnd