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 C0A3BC433F5 for ; Fri, 11 Feb 2022 20:13:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 02CFE6B0078; Fri, 11 Feb 2022 15:13:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EF8586B007B; Fri, 11 Feb 2022 15:13:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D71026B007D; Fri, 11 Feb 2022 15:13:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0009.hostedemail.com [216.40.44.9]) by kanga.kvack.org (Postfix) with ESMTP id C04926B0078 for ; Fri, 11 Feb 2022 15:13:19 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7A6C518128AF0 for ; Fri, 11 Feb 2022 20:13:19 +0000 (UTC) X-FDA: 79131598518.11.EA81B33 Received: from mxs1.seznam.cz (mxs1.seznam.cz [77.75.78.125]) by imf14.hostedemail.com (Postfix) with ESMTP id B9C92100006 for ; Fri, 11 Feb 2022 20:13:18 +0000 (UTC) Received: from email.seznam.cz by email-smtpc9a.ko.seznam.cz (email-smtpc9a.ko.seznam.cz [10.53.11.15]) id 6ca3cf4ff891bdd66bbed5ab; Fri, 11 Feb 2022 21:12:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seznam.cz; s=beta; t=1644610357; bh=IgtwdA4RN0Wg/7hbsEWLru8iFgUbT7+Jga+cWjzCwH0=; h=Received:Date:From:To:Cc:Subject:Message-ID:X-Mailer:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:X-szn-frgn: X-szn-frgc; b=TSlECtO1MvwQg6z6ntNkJpM6bWtiNBvrIhXhSLROT/yqfHK8p3UExbv1PywKgy8mz VhCR+ETL/Mb7OGTqpY2mQdF2vJiQz7oylXweEra5QbQa446vsVMJ0JoSEQY2C62yte 5mjztOGg8CK31AlcWSViqpK4PknDWf9r9JhJtcUA= Received: from PC (49659.s.time4vps.cloud [80.209.232.197]) by email-relay27.ko.seznam.cz (Seznam SMTPD 1.3.136) with ESMTP; Fri, 11 Feb 2022 21:12:33 +0100 (CET) Date: Sat, 12 Feb 2022 05:12:19 +0900 From: Alexey Avramov To: yuzhao@google.com Cc: 21cnbao@gmail.com, Michael@michaellarabel.com, ak@linux.intel.com, akpm@linux-foundation.org, aneesh.kumar@linux.ibm.com, axboe@kernel.dk, catalin.marinas@arm.com, corbet@lwn.net, dave.hansen@linux.intel.com, hannes@cmpxchg.org, hdanton@sina.com, jsbarnes@google.com, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mgorman@suse.de, mhocko@kernel.org, page-reclaim@google.com, riel@surriel.com, rppt@kernel.org, torvalds@linux-foundation.org, vbabka@suse.cz, will@kernel.org, willy@infradead.org, x86@kernel.org, ying.huang@intel.com Subject: Re: [PATCH v7 00/12] Multigenerational LRU Framework Message-ID: <20220212051219.183d1baf@PC> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) In-Reply-To: <20220208081902.3550911-1-yuzhao@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-szn-frgn: <2589a48c-6a4d-4565-a2e2-23674c43dbba> X-szn-frgc: <0> Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=seznam.cz header.s=beta header.b=TSlECtO1; dmarc=pass (policy=none) header.from=seznam.cz; spf=pass (imf14.hostedemail.com: domain of hakavlad0@seznam.cz designates 77.75.78.125 as permitted sender) smtp.mailfrom=hakavlad0@seznam.cz X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B9C92100006 X-Stat-Signature: uh36co3rdrra9jmtihfwfsctr8ch6rzo X-HE-Tag: 1644610398-499020 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001539, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Aggressive swapping even with vm.swappiness=1 with MGLRU ======================================================== Reading a large mmapped file leads to a super agressive swapping. Reducing vm.swappiness even to 1 does not have effect. Demo: https://www.youtube.com/watch?v=J81kwJeuW58 Linux 5.17-rc3, Multigenerational LRU v7, vm.swappiness=1, MemTotal: 11.5 GiB. $ cache-bench -r 35000 -m1 -b1 -p1 -f test20000 Reading mmapped file (file size: 20000 MiB) cache-bench v0.2.0: https://github.com/hakavlad/cache-bench Swapping started with MemAvailable=71%. At the end 33 GiB was swapped out when MemAvailable=60%. Is it OK?