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 D46AEC3F2C6 for ; Mon, 9 Mar 2020 13:33:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B8E4920727 for ; Mon, 9 Mar 2020 13:33:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726623AbgCINdq (ORCPT ); Mon, 9 Mar 2020 09:33:46 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:53183 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726427AbgCINdq (ORCPT ); Mon, 9 Mar 2020 09:33:46 -0400 Received: from mail-qv1-f53.google.com ([209.85.219.53]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1Mft3h-1jrX2P2EMT-00gDOE; Mon, 09 Mar 2020 14:33:44 +0100 Received: by mail-qv1-f53.google.com with SMTP id m2so4309429qvu.13; Mon, 09 Mar 2020 06:33:44 -0700 (PDT) X-Gm-Message-State: ANhLgQ2cGAClHxhhKYxLdxfmsD+WXhy1WPw1CGiz4PpyJrVPFMQhm1vZ gxUOAsFjnRqYkKxWoVVmtYkFkSBzVSkA5bYA5zg= 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:4Uk+eoxAdYLQYHRtietrYb/hTUc9UW68fZ0BAFbzJwMndYqTN4Y sTOPub1ZgVM71gXs3eC8FIDH0TINzzRgwsAbaNrajuJNM8rOOm+L5YzOyby0c2wyVccUHbS wvM2hT/dKoAJqHTNDktPnQmeRsPrd0uzzuqgJFJeAKkD+5iv7Er0Bp9nXGMn5MPodnNyptz gPERQcI/KqH3hodQSIklQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:H87OSnfdRG0=:3Huc2lYEQZdXcoQyysvwu/ MAAnJcFQsh7prCScZjCUCeiKCR14VSlb333panzZgcBxJAD2uCYrcZlk855x/hV/CoJY3jB5S PIbzwXAPWyb0iWqwH6ASOSNT8CduNHk3JQqdF5HWk7jhvHblMPjltBtU2PzToD7HhYgSOMjI7 Hn9ttSzzgQARATgxNtTmzDCmc91V4u84BSf6NRle04a8gvGmFU76fxdXk71UGDLSRhpQa3clg GqRxgn8w4TxBCmGZX6slaYcyHYKqe77Jdb1xYXAcuVVnMGqyWcYfsQaHdwpOnZLjIhmhGKKK2 /CbUu1MaRoat9o16AMShuyB+vYAqTcONL2pFPtW0+BUtAK7ZDl5IsaZv+/YgFpjo/MVAAKQTT R5Q2TF3c9b1n6kbWYNWGYo3mMjjcQIjf16meh9Hx+oMEdl5w+kPH5T269PZ1GvL2b9UJPMoDK 0+SdJZyP5Bgedn2COyuPlunE6Kyg1Oq4bslI4U48OyO7M4DKUFcEXrNfZRtzQT5YAUU9u9MTU 1eOuRu894Wc2tlJzylqH0lvsG6QZsukyJ5ZwcSN/JPMEVpdStFgfSQneRiGrOoI8aERZAS6ak JdSgN+jsLsO+M7m/G9qoDIFP8qH9V6KP0m0BGuPRszLZlUZgaKTVKY+6O4pNzetH97w9rIoAD 9ugEDpjccUr6wYECB76ZMdz1oSDdEYN0AePLPptxXIN5Oxwu+fOJVZUDXngIPrOSqPRvY4VBU +8rcPB4kJUA1r+HMyJjBivMwSPNM3+lIvUXOt/pjpURU8Hb6wrbU90B3YN3NiWKvdsKpCalGo 7XVzyBzrmdDtDpJKubwKCqqB5Q03xmGDsnypK3l5VBB5Eukits= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 F1250C10F27 for ; Mon, 9 Mar 2020 13:33:54 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BF80B21927 for ; Mon, 9 Mar 2020 13:33:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KfMmlEC1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF80B21927 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fctBP6s2K7JLHtaCOATlNw8w72pcsmtmNyS/USqTuVM=; b=KfMmlEC1EfEEqI uC59wnKNb7NtwHuW6umYUVlRIGxFHixQvvQB9F5XptxmykqdicpR7XiDIWBAiC4+6FcNZng+Sw1vu Pj2xlo7QA1IfAoAK9G1y9BpqqqoPk2GBxhakknQthHpf072A++/anyMQfYltkr8ub4EMA7wYk/saq Q2eMIQlvBO1TRHiXwWZbYe1MAvlgoR+pkSsOYuyVsAOJ1zQMRKV9v82nJLnVJVKkZJhsoMJUKCEoh 7b2tRTlPnR0rovXL/whDk0103q6/DC/QmUVW2WiY9Zj5eTtsc1vs8WZT6z9atO0gohAhD2iHb+7+v MVyMxnUzKKdqe9n0tP5w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jBIXZ-00072L-Hz; Mon, 09 Mar 2020 13:33:53 +0000 Received: from mout.kundenserver.de ([212.227.126.131]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jBIXT-00070u-Ud for linux-arm-kernel@lists.infradead.org; Mon, 09 Mar 2020 13:33:49 +0000 Received: from mail-qv1-f45.google.com ([209.85.219.45]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MCKO2-1j1z8E1g26-009Lwv for ; Mon, 09 Mar 2020 14:33:44 +0100 Received: by mail-qv1-f45.google.com with SMTP id fc12so4330293qvb.6 for ; Mon, 09 Mar 2020 06:33:44 -0700 (PDT) X-Gm-Message-State: ANhLgQ2BTsyEAySawhd7KIFWf62GfqpIjOCIzQbOS3OOTIUI4EE4wMNf kikXCyhzmCD1oEwbBQeio3t4IHwiwuRQLtZEWnQ= 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 X-Provags-ID: V03:K1:ewf9DmfAWT15ayrtbqjonevUP5cqRN+Ue/cVrwTGAG43isu3etE YSHO5/tgIYZYeigcrgJ7XW01jecDWXHmim41sXD3qROGrcIHNhpMAeBF1jKrEuwLkr6A5ZH QZ1KZE1nnmItOEIc3b6cBgA/Znu+LQaJokFLLbY3uPniC7J8S1l5EjEq9O0nLymSCb2a4Xk yk2WehadA/hwWXDlz2yjA== X-UI-Out-Filterresults: notjunk:1;V03:K0:v74YrZMsTNg=:cQirl8XdYt1uVinzrzUewy S/+w97BMmzL1LcHSHo3RVOQL09Reyd2QPH+UowMXFKge7ysAWZDP/Q7arJGKhjsoYqE+riwsa GMnabJrnjibB6qML24cgMN8iRhLTB+w/HNEFXur/4Z/wfDzYYmQsEQlrtL2y8zobepWdqZIko +IFrmWH5A39PP+qlITxQS5RUY+sIiFOIOER1t3XzjMl9l4gMFgSrVxAcWD0lW904UuxZFuY5n OGLLv0I1b0NHo9sf5hysU0E58jKQnR/A0hHEW3R2CwIKIlcnCa6PUSl1syyQ8To7pYGHzjXcR +5PdcXzuPtACoMgKo66E9QOD2oxJhwgIXOwzx0wuE5hHX6o4UP4SJBPGiofXYr8iRXbv3Rsbx OeFAvskq/61m+cbxi0ROn6zSk13cE82nujjkc8aTgXYEr6BY9TyOSthCwdr9BXjVKX2LGKzgD 6k3QQd/cI6KnneV/LCTi+pp/NiHnyFLD7t1W4NbOEm1Re2ip3tRdkoVUY9oV9/T8cFlO8swBD HPI5u9W1QwkJ7qh2XUsqwPASHO+Jl3Ve52TVyA197l037E0pNDK/InXgrJawDOQGWp/EUd4hy jsdNrHxj1LrcHg0XFkiIe9ywoxE6i2VncVSbyiRJxl3XVsKpemZ/BJ3VKBK55AUcxRPsTbNu2 eBqdQGMm7nsar+YPlhHjmoDB4Hmpl2saPw3mQ7TopkGuWn5LL8PtLJKSTigG0QdDhswo2t2ED nRatId+jONIn1TTUdgtjEk952LZOn+XZAl6YURZgV+pSPXsLVb2+jBggbWYzHcGHcunwwmA6J YrXyD6W5DfByVCmUSEcGwjXBvPMseZvOPmwUze+Wxo56o8OxHU= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200309_063348_280085_40FEC51E X-CRM114-Status: GOOD ( 21.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nishanth Menon , Michal Hocko , Johannes Weiner , Rik van Riel , Catalin Marinas , Roman Gushchin , Santosh Shilimkar , Dave Chinner , Linux Kernel Mailing List , Kishon Vijay Abraham I , Tero Kristo , Linux-MM , Yafang Shao , Al Viro , Santosh Shilimkar , linux-fsdevel , kernel-team@fb.com, Linus Torvalds , Andrew Morton , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel