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=-5.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,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 320CAC433ED for ; Fri, 30 Apr 2021 06:38:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C4E836135B for ; Fri, 30 Apr 2021 06:38:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C4E836135B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=yandex.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2E6326B00E4; Fri, 30 Apr 2021 02:38:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2BCB06B00E5; Fri, 30 Apr 2021 02:38:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15DF26B00E6; Fri, 30 Apr 2021 02:38:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id EAB426B00E4 for ; Fri, 30 Apr 2021 02:38:06 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9FE048249980 for ; Fri, 30 Apr 2021 06:38:06 +0000 (UTC) X-FDA: 78088078572.33.53F07D7 Received: from forward103j.mail.yandex.net (forward103j.mail.yandex.net [5.45.198.246]) by imf12.hostedemail.com (Postfix) with ESMTP id 5919B13A for ; Fri, 30 Apr 2021 06:37:54 +0000 (UTC) Received: from iva6-6951b41b66a9.qloud-c.yandex.net (iva6-6951b41b66a9.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:610b:0:640:6951:b41b]) by forward103j.mail.yandex.net (Yandex) with ESMTP id 300FD6742186; Fri, 30 Apr 2021 09:38:03 +0300 (MSK) Received: from iva7-f62245f79210.qloud-c.yandex.net (iva7-f62245f79210.qloud-c.yandex.net [2a02:6b8:c0c:2e83:0:640:f622:45f7]) by iva6-6951b41b66a9.qloud-c.yandex.net (mxback/Yandex) with ESMTP id 5N2zMeQbUu-c0JekTBT; Fri, 30 Apr 2021 09:38:03 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1619764683; bh=OSUWNyoDwSwSlzocc2rtb85rgBPEIJvV7CLDYga9B8g=; h=In-Reply-To:Cc:To:From:Subject:Message-ID:References:Date; b=VhdTpXInNPf84/gSeTMBd4JRaOujt6TrG9MVNvWn5bdA/lyjvde5vnCBWeUcH1DLi fnZPpqT+/ILh6zSFsr7t7gpoWIr1tGWrNYhwQo+urhbdPsrDwaDjJvttoLTObrUk03 8+MgeZw0uZRNZqxoV61Szyi0CNauM9L5/xP5X1uY= Received: by iva7-f62245f79210.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 3WbXfJvglC-bwL0109t; Fri, 30 Apr 2021 09:37:59 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Message-ID: <8ce5be3df2137e975d7333024b6120b71b214617.camel@yandex.ru> Subject: Re: [PATCH v2 00/16] Multigenerational LRU Framework From: Konstantin Kharlamov To: Yu Zhao , linux-mm@kvack.org Cc: Alex Shi , Andi Kleen , Andrew Morton , Benjamin Manes , Dave Chinner , Dave Hansen , Hillf Danton , Jens Axboe , Johannes Weiner , Jonathan Corbet , Joonsoo Kim , Matthew Wilcox , Mel Gorman , Miaohe Lin , Michael Larabel , Michal Hocko , Michel Lespinasse , Rik van Riel , Roman Gushchin , Rong Chen , SeongJae Park , Tim Chen , Vlastimil Babka , Yang Shi , Ying Huang , Zi Yan , linux-kernel@vger.kernel.org, lkp@lists.01.org, page-reclaim@google.com Date: Fri, 30 Apr 2021 09:37:58 +0300 In-Reply-To: <140226722f2032c86301fbd326d91baefe3d7d23.camel@yandex.ru> References: <20210413065633.2782273-1-yuzhao@google.com> <140226722f2032c86301fbd326d91baefe3d7d23.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.0 MIME-Version: 1.0 X-Stat-Signature: hmd58dt4bbmmwcefmiph66cdyofsfn1n X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5919B13A Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=yandex.ru header.s=mail header.b=VhdTpXIn; spf=pass (imf12.hostedemail.com: domain of hi-angel@yandex.ru designates 5.45.198.246 as permitted sender) smtp.mailfrom=hi-angel@yandex.ru; dmarc=pass (policy=none) header.from=yandex.ru Received-SPF: none (yandex.ru>: No applicable sender policy available) receiver=imf12; identity=mailfrom; envelope-from=""; helo=forward103j.mail.yandex.net; client-ip=5.45.198.246 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619764674-818416 Content-Transfer-Encoding: quoted-printable 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: Btw, I noticed a fun thing, an improvement. I don't know yet if it can be attributed to 5.12 (which I didn't try alone yet) or to the LRU patchset,= but I'd assume the latter, because 5.12 seems didn't to have had anything interesting regarding memory performance=C2=B9. I usually have Skype running in background for work purposes, which is on= ly used 2-3 times in a week. So one would expect it to be one the first victims t= o memory reclaim. Unfortunately, I never seen this to actually happen (till= now, that is): all skypeforlinux processes routinely have 0 bytes in SWAP, and= the only circumstances under which its processes can get into SWAP is after experiencing many SWAP-storms. It was so hard for the kernel to move thes= e unused processes to SWAP that at some point I even tried to research if t= here are any odd flags a userspace may have set on a process to keep it in RAM= , just in case that's what happens to Skype (A: no, that wasn't the case, runnin= g Skype in a memory limited cgroup makes it swap. It's just that kernel decision = were lacking for some reason). So, anyway, I am delighted to see now that while testing this patchset, a= nd without encountering even a single SWAP-storm yet, skypeforlinux are one = of the processes residing in SWAP!! =CE=BB smem -kc "name user pid pss swap" | grep skype =20 skypeforlinux constantine 1151 60.0K 7.5M=20 skypeforlinux constantine 1215 195.0K 8.1M=20 skypeforlinux constantine 1149 706.0K 7.5M=20 skypeforlinux constantine 1148 743.0K 7.3M=20 skypeforlinux constantine 1307 1.4M 8.0M=20 skypeforlinux constantine 1213 2.1M 46.1M=20 skypeforlinux constantine 1206 14.0M 10.8M=20 skypeforlinux constantine 818 38.5M 34.3M=20 skypeforlinux constantine 1242 103.2M 46.8M=20 !!! 1: https://kernelnewbies.org/Linux_5.12#Memory_management On Fri, 2021-04-30 at 02:46 +0300, Konstantin Kharlamov wrote: > In case you need it yet, this series is: >=20 > Tested-by: Konstantin Kharlamov >=20 > My success story: I have Archlinux with 8G RAM + zswap + swap. While de= veloping, > I have lots of apps opened such as multiple LSP-servers for different l= angs, > chats, two browsers, etc=E2=80=A6 Usually, my system gets quickly to a = point of SWAP- > storms, where I have to kill LSP-servers, restart browsers to free memo= ry, etc, > otherwise the system lags heavily and is barely usable. >=20 > 1.5 day ago I migrated from 5.11.15 kernel to 5.12 + the LRU patchset, = and I > started up by opening lots of apps to create memory pressure, and worke= d for a > day like this. Till now I had *not a single SWAP-storm*, and mind you I= got 3.4G > in SWAP. I was never getting to the point of 3G in SWAP before without = a single > SWAP-storm. >=20 > Right now my gf on Fedora 33 also suffers from SWAP-storms on her old M= acbook > 2013 with 4G RAM + zswap + swap, I think the next week I'll build for h= er 5.12 + > LRU patchset as well. Will see how it goes, I expect it will improve he= r > experience by a lot too. >=20 > P.S.: upon replying please keep me CCed, I'm not subscribed to the list