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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1558DC433FE for ; Mon, 10 Jan 2022 14:49:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 681F96B0073; Mon, 10 Jan 2022 09:49:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 630EF6B0074; Mon, 10 Jan 2022 09:49:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F85C6B0075; Mon, 10 Jan 2022 09:49:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0064.hostedemail.com [216.40.44.64]) by kanga.kvack.org (Postfix) with ESMTP id 4043A6B0073 for ; Mon, 10 Jan 2022 09:49:51 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DFC80824C421 for ; Mon, 10 Jan 2022 14:49:50 +0000 (UTC) X-FDA: 79014661740.27.C3133D6 Received: from shark1.inbox.lv (shark1.inbox.lv [194.152.32.81]) by imf26.hostedemail.com (Postfix) with ESMTP id 32B9B140006 for ; Mon, 10 Jan 2022 14:49:50 +0000 (UTC) Received: from shark1.inbox.lv (localhost [127.0.0.1]) by shark1-out.inbox.lv (Postfix) with ESMTP id 048B61118140; Mon, 10 Jan 2022 16:49:48 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=inbox.lv; s=30062014; t=1641826188; bh=v8M5awXlRgm8CQPFWrxz5Yn/2aXPYkjUaIMnTlnA2j4=; h=Date:From:To:Subject:Message-ID:In-Reply-To:References: Content-Type:X-ESPOL:from:date; b=ETkKyFBSqlmwxhHpOAPlyeai+0JG5EsOAxPGfHaxqA+mKrNVrafW5wHuqE9QQOdMj fkYp9FiHF5ouPE742u0Z4OYws+vdRodvMKwZg4yPdnwSk2m8KG7fxrtK2j6yOU0Fju hYNdJxDDysBQmZCy8v1k5aZExcslKHO6gl19u3Sw= Received: from localhost (localhost [127.0.0.1]) by shark1-in.inbox.lv (Postfix) with ESMTP id EDA2011180B4; Mon, 10 Jan 2022 16:49:47 +0200 (EET) Received: from shark1.inbox.lv ([127.0.0.1]) by localhost (shark1.inbox.lv [127.0.0.1]) (spamfilter, port 35) with ESMTP id 49NQ99mX1Zp1; Mon, 10 Jan 2022 16:49:47 +0200 (EET) Received: from mail.inbox.lv (pop1 [127.0.0.1]) by shark1-in.inbox.lv (Postfix) with ESMTP id 9C3971118085; Mon, 10 Jan 2022 16:49:47 +0200 (EET) Date: Mon, 10 Jan 2022 23:49:32 +0900 From: Alexey Avramov To: Yu Zhao Cc: Andrew Morton , Linus Torvalds , Andi Kleen , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, page-reclaim@google.com, x86@kernel.org, hakavlad@gmail.com Subject: Re: [PATCH v6 0/9] Multigenerational LRU Framework Message-ID: <20220110234932.6eb6c356@mail.inbox.lv> In-Reply-To: <20220104202227.2903605-1-yuzhao@google.com> References: <20220104202227.2903605-1-yuzhao@google.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: OK X-ESPOL: AJqEQH8B6gpL2qWiUuRh4Or6x9a2SFs9vyXmrMk96HRYtbrGu9h2dXPmZYmvRkKl X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 32B9B140006 X-Stat-Signature: uuf6ycu3sfc9ifn3g3n3ww7bssrommsi Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=inbox.lv header.s=30062014 header.b=ETkKyFBS; spf=pass (imf26.hostedemail.com: domain of hakavlad@inbox.lv designates 194.152.32.81 as permitted sender) smtp.mailfrom=hakavlad@inbox.lv; dmarc=pass (policy=quarantine) header.from=inbox.lv X-HE-Tag: 1641826190-859304 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: Note that with vm.swappiness=0, the vm.watermark_scale_factor value does not affect the swap possibility: MGLRU ignores sc->file_is_tiny. With the classic 2-gen LRU swapping goes well at swappiness=0 and high vm.watermark_scale_factor, which is expected according to the documentation: "At 0, the kernel will not initiate swap until the amount of free and file-backed pages is less than the high watermark in a zone." [1] With vm.swappiness=0, no swap occurs with any vm.watermark_scale_factor value with MGLRU. I used to see in practice (with MGLRU v3) the impossibility of swapping when vm.swappiness=0 and vm.watermark_scale_factor=1000. At a minimum, this will require updating the documentation for vm.swappiness. BTW, why MGLRU doesn't use something like sc->file_is_tiny? [1] https://github.com/torvalds/linux/blob/v5.16/Documentation/admin-guide/sysctl/vm.rst#swappiness