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=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 92235C10DCE for ; Sun, 8 Mar 2020 14:20:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4838020637 for ; Sun, 8 Mar 2020 14:20:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="K5AdU8Ce" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4838020637 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F225F6B0006; Sun, 8 Mar 2020 10:20:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ED2916B0007; Sun, 8 Mar 2020 10:20:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE9846B0008; Sun, 8 Mar 2020 10:20:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0210.hostedemail.com [216.40.44.210]) by kanga.kvack.org (Postfix) with ESMTP id C925A6B0006 for ; Sun, 8 Mar 2020 10:20:30 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8B27D8248047 for ; Sun, 8 Mar 2020 14:20:30 +0000 (UTC) X-FDA: 76572405420.21.home04_217a3bc29fb26 X-HE-Tag: home04_217a3bc29fb26 X-Filterd-Recvd-Size: 6531 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Sun, 8 Mar 2020 14:20:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IVcvIDGwJZYeIvUKfXFgN/rhffyZlyGXJDMHZ+yeVcA=; b=K5AdU8Ceyd0YtsCSwH4Hj1L38 t2ufNPUr4XC7GAFtajzsm47ier9yjsvWFQFWu0mCa1G7QppuiMbitZqbvPb4aJTWZ6pJLLx5Vshe/ v2GvvL//7hb/7KOIAClcoZKG+252QJOCA2dceM7z7uL5PQHeC+XBtuH35BLfESIsNh8UZSSXotv36 IcQJ6QRe3rswhZLX5YD26pP6u/QHUOsyEf8Nxkcs4Mw2s76sw15OdagnLghnPml3AGrTEiVnAoOe0 DrgNb5R9cwFl1AYqDm4dBYoVPLxS++dlkn7dtqHabMQYYxUTAnLekyjyDyNA/t5H9PRrwV9RJoYw7 I5Ik0L//Q==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:33732) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jAwmE-0000p8-0s; Sun, 08 Mar 2020 14:19:34 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jAwm3-0002Se-Bj; Sun, 08 Mar 2020 14:19:23 +0000 Date: Sun, 8 Mar 2020 14:19:23 +0000 From: Russell King - ARM Linux admin To: Arnd Bergmann 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 Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU Message-ID: <20200308141923.GI25745@shell.armlinux.org.uk> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 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: > > > > > ~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. 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. 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. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up