Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2505978ybh; Mon, 9 Mar 2020 07:15:44 -0700 (PDT) X-Google-Smtp-Source: ADFU+vt6qASR+I0PcBiBpcO6K3WIif7XNteXLahZHerawRNrQ9x5yVW7wjhI1OwvRPmjkyU2u7Pz X-Received: by 2002:a05:6808:315:: with SMTP id i21mr11006132oie.139.1583763344321; Mon, 09 Mar 2020 07:15:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583763344; cv=none; d=google.com; s=arc-20160816; b=znwqHzmqyV4lLUu0QCP9f9mUEqvMg+m61M0p4209+D0iAUGmBsdZw0Hepbx1sWzjsT ZyuuIogSsirO4NRRbNl/1ZrdhGKkh5UBBbmpPYY79TeTlWakKbHb2yVgxXkEBWNv/WUC GV6igCm2vLvtZNV0k89mEG9DkpA+b0XlazGPtQqi7jwoe+5lX4/kTmNuggaA52441Ubx wmjSEh0bJItBhG165au3yst3phdWw5beB6okvSMRWhPKRDapaOI+pi2Wrx7jM0unh6jF 5RtmAbM9eTtRa2OGPaBizPlQk39yqwdlZfVxuGhK/I8yIh+A2+ou5AwH5DPbl6PrdRdf RQQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=d26Ye+vMRYj5g5ykorwl/W5eqkd9joFbNEWspN4ENAs=; b=gPo9rtS59k7I9l52Iim0ru62AiSs+n68SrltFg9N4v8plw+Vb9El0MMkBsLWjvkMmX HNfer+WHrsFIUdz56z3HLz7JkAo2rc7fNZR3bzKc9knSxdqEdYwfeA/rlG+O4ww/OTM0 8ZVmvw9vY8gAhDVKP+aGK8qFiIltXWStVsgi4FjFEzga50uH9lxejE4xcfAgKrjGKr9R TQYdRjA4+ndbBPSTn91SvXbzmjCtSicEaD2RikkpizIxiEbJ3CeVHis/unStlfmLhIII FCByvOy5/D8f1w9HKlroI0pDbVlx6kAIZISrk3miT3V6Yc7zPfIN0GWBNLRb7pu4iFYk Zqwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=Xl4UNnGt; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 96si5165361oty.198.2020.03.09.07.15.32; Mon, 09 Mar 2020 07:15:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=Xl4UNnGt; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726825AbgCIOFB (ORCPT + 99 others); Mon, 9 Mar 2020 10:05:01 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:49144 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726275AbgCIOFB (ORCPT ); Mon, 9 Mar 2020 10:05:01 -0400 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=d26Ye+vMRYj5g5ykorwl/W5eqkd9joFbNEWspN4ENAs=; b=Xl4UNnGtpQtUvm2BgVXiCnesn 7sfNE6HTuF5M1sEiacWYVtLUj7JcKknJbqaOlmfa4Uc1uchICRc2UPtoZKgJ0Z4TIX9KenW7nmUtk jmKticzXy8ktdt2H4UZBTcBKr1oqKdgzkaVXoyOHbYCTnXmzv7j7ETY8ebK4+jq9qBgW1p3TbEVdp iMM3SFdsMiP7+ayIeGrD3Lh5qVn0R0EmfK9Ubo8B0qSyLSX6K+7nW1r6FIzw6VM/1qJeGmbKeg0bK f1I3tsqkvGx8S3xga4Nb3k3LYM0BLa3gIM5rWVU8XT09RkrZFk5zOv1Eqy34iooGn9DOWutdB77v4 BXyB9MVUQ==; Received: from shell.armlinux.org.uk ([2001:4d48:ad52:3201:5054:ff:fe00:4ec]:50736) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jBJ1T-0007Ja-5X; Mon, 09 Mar 2020 14:04:47 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jBJ1L-0003Qb-Vi; Mon, 09 Mar 2020 14:04:40 +0000 Date: Mon, 9 Mar 2020 14:04:39 +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: <20200309140439.GL25745@shell.armlinux.org.uk> References: <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> 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) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 09, 2020 at 02:33:26PM +0100, Arnd Bergmann wrote: > 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. You are suggesting for a 4GB machine to use 2GB of RAM for normal usage via an optimised virtual space layout, and 2GB of RAM for swap using ZSWAP, rather than having 4GB of RAM available via the present highmem / lowmem system. I'm saying that is quite risky given the behaviours I'm seeing, where modern Linux seems to be struggling to work out what pages it should be evicting. I think Linux performs way better when it doesn't have to use swap. > > 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. I think that's still a very open question, one which hasn't been answered yet. > - 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. How do you come up with that assertion? What is the evidence behind it? This is kind of the crux of my point in the previous email: Linux with swap performs way worse for me - if I had 16GB of RAM in my laptop, I bet it would perform better than my current 8GB with a 16GB swap file - where, when the swap file gets around 8GB full, the system as a whole starts to struggle. That's about a 50/50 split of VM space between RAM and swap. Proposing 2GB+ swap 2GB RAM would potentially place these machines into the same situation as my laptop, and if it also results in a loss of performance, we could end up with regression reports. > - 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. What happened to requests for memory from highmem being able to be sourced from lowmem if highmem wasn't available? That used to be standard kernel behaviour. > - 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. I think the chances of that happening are very slim - I doubt there is the will to invest the energy amongst what is left of the 32-bit ARM community. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up