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 317E1C072A2 for ; Fri, 17 Nov 2023 16:28:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 96BAF6B04FD; Fri, 17 Nov 2023 11:27:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 91A796B04FF; Fri, 17 Nov 2023 11:27:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E2596B0500; Fri, 17 Nov 2023 11:27:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6F4816B04FD for ; Fri, 17 Nov 2023 11:27:59 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4863C1A0622 for ; Fri, 17 Nov 2023 16:27:59 +0000 (UTC) X-FDA: 81467977878.26.3E49AFE Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf04.hostedemail.com (Postfix) with ESMTP id 773A64001F for ; Fri, 17 Nov 2023 16:27:57 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=gXH0LccM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700238477; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gYMqLtzHxtjl/0RXubUExMnoFoWXnrJhTRzwPVlfA/Y=; b=3eic5oOyVv2En9KLO+4ui38HI3Y0GapvL3KzMfbCH0XtisPLX04UWOTH4X83g/WcznbCHe EP1s8a3DxA7+ULyFwVsDgdsxvEBTpG1rZS+gfRBzW0/qnlFnkSxMmIPLf6LrfVMJ0+FBBi mZRocQ7DG5Zui22lLllVIVRY9bCtFIo= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=gXH0LccM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700238477; a=rsa-sha256; cv=none; b=Z4ZAp5VXwpvUfAgU4xuPGgsatA8y5TUmzKGyaJ19CL2Myp8VUEpXwDDCghjuvpRG3CQ6F0 OvboiL7nk2eWfvKktO5Ojf+odw5PX/Bj/5eY2q9Dp7WvXvtYHzTSp3gmZerJ58TKQBYD+W 1c0FXZ81LNtc/JysgpZoQleNxrfwFO0= Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-9dd3f4a0f5aso302057466b.1 for ; Fri, 17 Nov 2023 08:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1700238476; x=1700843276; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gYMqLtzHxtjl/0RXubUExMnoFoWXnrJhTRzwPVlfA/Y=; b=gXH0LccMRLkZYMzWj4nMMlmMBrlif+qP8aXrZqYJKPVwgE/1DMTy1mMTrd+x+TjcD8 Fec9yYIFh77yFJZTcO7caiR+S3J2tmBZQlLUyvWLIB13G9YUYDaR4nkVILEmUayODqQK TfdaBwP0bFeJ2rp9eo4a4PqWTNCBRaHmM18XHIfSa/MHGOpypt403OJSkBd9d6dhIoXS SjEiOTdyC+dManpWkhvxs+UjyRPCKAMFMBpw1NFRvmYfqxhk3cRqNn2BccWH6GkUsU79 5x1PLMdxypZ38s+ofePjkwfIge+kphhWtYIxI8mOyAOmJDGnG27LYDIR7y2n1B2u7Pw9 Hmaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700238476; x=1700843276; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gYMqLtzHxtjl/0RXubUExMnoFoWXnrJhTRzwPVlfA/Y=; b=qH1yjKrLPZZvEcoKZGCfQsJKxNW6O3aTHEeA0jx9KBpWaYWDuZ1T3jjs7IeBvY3Pgf lt2dyJbKGW05mtHEBpSx2psFLEJAv68HBG6WMg2COwoIc949qqpIOsWfn0Gki0pRxl+Y 1kA+OgSgVhNKYbJrQzSojaYCt4bzL70ToJ/wyyiP4g52rw+dNKFchKjna5mhpU7XCQQ1 Hi3Pp0AU5lKH5cHqFg/kbuFbvpS2lINTnvYRZ3WUPokatEZa1C/z18mJ3EeeVBZvX/7M 4EH041erTo1+z3JVuwnqEWMdNGn9+O1zxKUN3I2LOjHtLpUyTpPiuzEHj6AFb/Tjw5io AhBg== X-Gm-Message-State: AOJu0YyKOJ3dD7KKfbWhJ0PA1RWozwKv5nRovroAs48+eY977OJQt38O eepFODS93mwRfcOvivvzlp58BHMzTu93kzQX9V8OwQ== X-Google-Smtp-Source: AGHT+IEML2McgqDhAm45vIc1lFPoPUKG88o0mJfcTJLxdrkvWDPgtUP33cqgTr1QEig22HevOk8eVl5Y/JCJy2Pl7rw= X-Received: by 2002:a17:906:f0c9:b0:9f6:15ad:cbf5 with SMTP id dk9-20020a170906f0c900b009f615adcbf5mr3764249ejb.15.1700238475782; Fri, 17 Nov 2023 08:27:55 -0800 (PST) MIME-Version: 1.0 References: <20231106183159.3562879-1-nphamcs@gmail.com> In-Reply-To: From: Yosry Ahmed Date: Fri, 17 Nov 2023 08:27:17 -0800 Message-ID: Subject: Re: [PATCH v5 0/6] workload-specific and memory pressure-driven zswap writeback To: Nhat Pham Cc: Chris Li , Andrew Morton , Johannes Weiner , Domenico Cerasuolo , Seth Jennings , Dan Streetman , Vitaly Wool , mhocko@kernel.org, roman.gushchin@linux.dev, Shakeel Butt , muchun.song@linux.dev, linux-mm , kernel-team@meta.com, LKML , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, shuah@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 773A64001F X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: hy7oy51rsw81616m6qd8im1kfedipzi4 X-HE-Tag: 1700238477-216552 X-HE-Meta: U2FsdGVkX1/xztOKLtLAx6U2ExxLRBl+6qEd2s2iY7rW2s9ORuCnEIar6M5BIRg2Yp/Mvbka0VIocdxhinos0KA13Wk5gwXOObXwe4rWig0KHSg/Un0YfR3iLJy0PbGusiRyokMp8GViKIkeyax4CNinWKRqnpUdK2UI3wEenFL5UDqCWF06SfLJD/IPbGejJfbCiIyXcaUGY1cilrnFbCvCsyfHgz6RAUIsyUrugsqmASW/cE5cyImEvXcvdJBc/cxdUqcVwebBzAJ5mL2bjzyj274zMW+4SAsfx8sJh3LvU4Tc3GO8SNBOBG4pk82+fxlSWf24v5YK20ovhfzSRq+iIRZgKrDv8WIUe2qtlAhyQNu1yFvla33bcm4jsvf1vzvWMq/JM3l8NQgiPj2dvH+1YQbX+escLug0K/MhZ+AKPB0is1d2jgU1k+pZKixvrNWQuMgLxiONZ58zrmMICQWJI9JzcuP3eHKlo2ND4eopLJ1ZHeHR0EIK47lqwi2OsKgAPPuWeqRF2HeJb6iZ5CEAZFh5in7T+UoHpK2Wd49ua5wS5eQbE3d7MkRxxCrieeezeY04q4sg4Mi8ujt+64Bq1MOoNZwXsRcV6IHFCzfeUfhOhbFsd2Ivi4ESQ0mk/gCYvFvDwK6ec6YXOYDe/9uKRGxY4+79mmBBygHhm0GO73y47kiuvTD5Q08SjB+5d7QcYFKoVbU26KCFeEoLZNH7f0nU0FlkRi+Mr02MZBceJLxWK3xmIF3LRD/ebOJxYQTVVH9cvT9fO7P2MlGe5DZzTcmE75yvStRowsW6wpOuijQfEesBecWpG973DdMGXggbOdsGxj6IG25gAIdw+ne/viPj+5BPnLzXfw/ToSWKnrWl9knHK4VKIH6Xspuru87QCPSPca3tWBqz1+8BSQsmyBCM+9IzO4KsMC9OO1eO5nXMvxfm5czXywgma9PUjBb4JC/L19PrKKn76g2 FtFNu/AT Atd9cWHAv02WNHoGbQ4dt839cBnaqHe8DdZWXEiKL7GIf8QPbsY9fMDWlhAMRPWNlQzSjI+3Fex0M63KEUIE0Cn0qUspHHjUKoblIhNOhTxmze6mmUkw58uEPWhh94UVsle7enAjut/ve2gryzbVkVUgPENRGoJeA3cOmanL6xTNFmQyKuS2ejfskBCka0xTt/+f1LR0XqEQBiYZ90XqjjxzUrvrlPDYjK493xGEDIZv85gu4wXmjnDHop+TDkSPnpfiKxpqz/sGr4ypoFpBxColtSXLDs/nHxD6P7Ib16biCt8Q6tZLpmXZV6h/wfGIJZBsOFrGFbT11+8g= X-Bogosity: Ham, tests=bogofilter, spamicity=0.019672, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Nov 17, 2023 at 8:23=E2=80=AFAM Nhat Pham wrote= : > > On Thu, Nov 16, 2023 at 4:57=E2=80=AFPM Chris Li wrot= e: > > > > Hi Nhat, > > > > I want want to share the high level feedback we discussed here in the > > mailing list as well. > > > > It is my observation that each memcg LRU list can't compare the page > > time order with other memcg. > > It works great when the leaf level memcg hits the memory limit and you > > want to reclaim from that memcg. > > It works less well on the global memory pressure you need to reclaim > > from all memcg. You kind of have to > > scan each all child memcg to find out the best page to shrink from. It > > is less effective to get to the most desirable page quickly. > > > > This can benefit from a design similar to MGLRU. This idea is > > suggested by Yu Zhao, credit goes to him not me. > > In other words, the current patch is similar to the memcg page list > > pre MGLRU world. We can have a MRLRU > > like per memcg zswap shrink list. > > I was gonna summarize the points myself :P But thanks for doing this. > It's your idea so you're more qualified to explain this anyway ;) > > I absolutely agree that having a generation-aware cgroup-aware > NUMA-aware LRU is the future way to go. Currently, IIUC, the reclaim logi= c > selects cgroups in a round-robin-ish manner. It's "fair" in this perspect= ive, > but I also think it's not ideal. As we have discussed, the current list_l= ru > infrastructure only take into account intra-cgroup relative recency, not > inter-cgroup relative recency. The recently proposed time-based zswap > reclaim mechanism will provide us with a source of information, but the > overhead of using this might be too high - and it's very zswap-specific. > > Maybe after this, we should improve zswap reclaim (and perhaps all > list_lru users) by adding generations to list_lru then take generations > into account in the vmscan code. This patch series could be merged > as-is, and once we make list_lru generation-aware, zswap shrinker > will automagically be improved (along with all other list_lru/shrinker > users). > > I don't know enough about the current design of MGLRU to comment > too much further, but let me know if this makes sense, and if you have > objections/other ideas. > > And if you have other documentations for MGLRU than its code, could > you please let me know? I'm struggling to find more details about this. > This could be a good place to start: https://www.youtube.com/watch?v=3D9HvJfN21H9Y