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 9C52FC25B74 for ; Fri, 24 May 2024 23:13:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 095C76B0085; Fri, 24 May 2024 19:13:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 046046B0088; Fri, 24 May 2024 19:13:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E76A76B0089; Fri, 24 May 2024 19:13:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C96C96B0085 for ; Fri, 24 May 2024 19:13:09 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8084BA1F86 for ; Fri, 24 May 2024 23:13:09 +0000 (UTC) X-FDA: 82154842098.12.BC8823F Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf12.hostedemail.com (Postfix) with ESMTP id A525B40013 for ; Fri, 24 May 2024 23:13:07 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=NSNY1pR8; spf=pass (imf12.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716592387; 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=QLe89AfXNhx0q2K1ygphHX7RVDhsSbjLXuCJH9i7f18=; b=RcLfuLYCRpTc/50ENPCqFn1niP0vYt5g2+nUErVRHv7zpkABsuGhAHO3I06aaWaFbMwaHn YeXDqrsV0WSrvfGY//ogvBCauyy0z1MT+RxpUjkdpTKkgHmueY8DkWzgJ0aFIkIIw9v+oh mzsPJziWgTcCj8HoYhZTEXJ7hImMqOU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716592387; a=rsa-sha256; cv=none; b=wnDzxIXGZADZuOl6Dv93mvW5l37z6gGwikS17K31Zr6qPo9UmlZxqc7uKJ1vkl/GPzy4A0 PueT99+p1Rlwpwv7v3p7IJzVrLnxqkSt1eYOqqccq1+VeBUR+PFpuvhwUSw6UIKszIQAGD powT3dUbixF4kPuh52kKwTSdjik8ARQ= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=NSNY1pR8; spf=pass (imf12.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-5785e443cf4so1267642a12.3 for ; Fri, 24 May 2024 16:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1716592386; x=1717197186; 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=QLe89AfXNhx0q2K1ygphHX7RVDhsSbjLXuCJH9i7f18=; b=NSNY1pR8VIgv01INbhlLWzkvNzd/mdRBFsoasdQDbg9H90itoT6FrwIW1a8NfXveCd tMj5nNWkZZ5LKr3kTTHF/mVgTfEDJhAdu8icfrSP9jPmjSfmU5jh5PSplwlqEoY/6cnW 4TDBFf+p0WrY6/g1HqDjJfoB4OlfNPqoJruy7btjke5jjxI82/pUyibDbWSs5mwx6P+8 e3/TUGzMXblA+baeBojMezOVhGWGnILmhWxqzIzB+fi+PErX8Zg+FU6M6e6gZpo1UGc1 BtYJCdyTSJ3MurP+RTV8AHezBoHthlT8OECKyp1atlk5x1O4H6K6APcx6B609HIxMXLr Sgkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716592386; x=1717197186; 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=QLe89AfXNhx0q2K1ygphHX7RVDhsSbjLXuCJH9i7f18=; b=SRngsoyjSOjqTmSojzjsA/gvfOJl8HRA1Q8kTt+HCRWh1V0Svj95JgGH8r1fXXR510 nlENL7ngKz3gkWYpATf+ZCCxFtrEl2Crm4qX5yGWsutPSC7+Lq+/jnlsKkAkdIuH/Xf9 zdMc5e5ykLeESGd7XwCOUH2JGHgNS3bpo9KTe4Wvbb1eemfefbHElMHmsH1sk+Y5fAIm PfymYSQwMwgdpW5QTdvSkoZ5PuQLz/D+gc45n5E6vK1c+whavMiKAI1aIgD+ajy/BKG3 Ouc1+QRyvVJQv+dz4mkuSJ+hmLcXNhBBvFPbF21uWbV/o8gSFXGb+Rq/cWG8bT6K1ahP lQMw== X-Forwarded-Encrypted: i=1; AJvYcCWRu/9e+UtfbWQi5kx2OzNpanc1WZry6Rv47fFKbM3J4cDIiHx6L5E6vuPsJrI9X6NnuvdMZX9IHfL8UdvQf3kiss4= X-Gm-Message-State: AOJu0YzMcIOUbkA7+oCfm7n0uRjjN4rICclSMbXDPQrK5Ikt9wScG5cD 1QJ7fdigCn44TCGzdiIto08DY6Pc9VKoPm3vxKk6QO4EUhnSBJYGvd1kJpfwehuD/C5M8rw0lhH 64D5tImPlaxAEVFTg9y/Gbg2FTaftq5tgEFcw1/KR7kiYsb4ZIDX2 X-Google-Smtp-Source: AGHT+IGOPz4oO6pvIvbUfEl8tKZ57eHs7hlulI2gwZf+y/bFnU/Wd7gUnGxTB+xwlS+B9tcS+usVvLSYNZehJgqoxcg= X-Received: by 2002:a17:906:38cf:b0:a5c:dd34:25e7 with SMTP id a640c23a62f3a-a62642d894fmr229037466b.1.1716592385666; Fri, 24 May 2024 16:13:05 -0700 (PDT) MIME-Version: 1.0 References: <20240524033819.1953587-1-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Fri, 24 May 2024 16:12:27 -0700 Message-ID: Subject: Re: [PATCH 0/3] mm: zswap: trivial folio conversions To: Matthew Wilcox Cc: Andrew Morton , Johannes Weiner , Nhat Pham , Chengming Zhou , linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Hildenbrand , Barry Song <21cnbao@gmail.com>, Chris Li , Ryan Roberts , Kairui Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: z5agu9h8c5i9z581fum4hnjymqn461en X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A525B40013 X-HE-Tag: 1716592387-140703 X-HE-Meta: U2FsdGVkX187FX3PnqTT+5d89+XoiATXdMlOQA4qVADWD20xs3uWa8QkiNHU0o1oFaRKnflI06T0dJX2DZ/1ttsGMe8WfrpxksY2rmqlUWklrbvNE7x1wzn1i7dYvL68NouTPMh11IAk46w/AbIJ+3rECQ2WrBs24MvqIKIAqBSYi6j5tl0qQBNFzzIqyB9blnPfLidyEC7mg9CDqOtORZxrXCafLviiFKqocpPbNtLi90o9JfgSWBsCyxVtJgSSJRzEaliC6+Zgyu2wK3tOAk/eK64s5CqvB/n+Vauk6P7GOIs7vEcpSwDE9L8Nby1wQxYPuJ0OcflQE1exuIbXSrKDLK3KInWezA8ciYpicDQcTKjHiAT7cbFQmN0UzUJsuZytPEx0kMHt+SSpOqze5fT91VT6idQjXrkbkG/hAvy66TXWKpldHZ7F35gOoXzgmC2HpCZqTghDTzVPYTp0RfqqWq21NaCNL53LyBWPlZP220BBuM5eMcoRqAu2przVRGS0oAZzRBOtqrINZWbWTXF8Rv6im2HOnp18tXxY4u4Hg6F3SWyzvX+pVc4Ec5hd7ejADYllWCGoLFV/3dkaamSjjFdnupQ/FzxuPPeiHTRMORSrYoAQ5UqpP64ROfl+dgEOFlZneV//qGSxGpvQ2+0PBypKCArrtyevG+vEKRzfqRp//vdTuR6nkeIi2f4vk3FnZAc5UtSx3mS9tOHofGO8MI/Rzq749u3cT9E+06Fo5tvH0pP4MPQ7omZzCFA0iU2yaaMj8ZdY8dt/I8Roc7Q4HdhjDHtdcZAk9iqLl8B6cllTurbKDQSea7aHKu4FuFnaA25r5FVJa5Fl0p/d/GVfXbVgsL1RSntY17wDOATq6VYs3ZsrVxe+1bcF1IYFbXreyhaY2JtHZsQJDi+3ZDZx7amZZUQw0dnJqNmg8ecMLEvEKCPwksN8WVrtXXsImQOuxAiXV6s3CvdXgh/ jMN5Wook z9Z1fOFGvfN8znTvFeTz8WDJa7fvhnMWK+189rgtpRgghV62qad7vigCpb9LNr9sgLnPe+o8jv1e+K15GDhbgtyLMfN9SbJI+pCC68exJ01RZVbU9cwiC1TFqDPz9GWUejnaNdEVTDlLKHSr/eVx2lvd5LltNxn5/AFVlostpUSRLbUMrP9hWgu1Cs60e1OpQjlnquPyPEabnFajzqmH2zq6FDWgLpOv4RfDeq95F7syU76OxW8OIrKg4N0+Z5EvFGzjZShAe2qlbdnkvEUbx0sdfbt3lP+2yDTsn7Fp494tfzyKuWG5sklpNXQ== 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: List-Subscribe: List-Unsubscribe: On Fri, May 24, 2024 at 12:53=E2=80=AFPM Yosry Ahmed wrote: > > On Thu, May 23, 2024 at 8:59=E2=80=AFPM Matthew Wilcox wrote: > > > > On Fri, May 24, 2024 at 03:38:15AM +0000, Yosry Ahmed wrote: > > > Some trivial folio conversions in zswap code. > > > > The three patches themselves look good. > > > > > The mean reason I included a cover letter is that I wanted to get > > > feedback on what other trivial conversions can/should be done in > > > mm/zswap.c (keeping in mind that only order-0 folios are supported > > > anyway). These are the things I came across while searching for 'pag= e' > > > in mm/zswap.c, and chose not to do anything about for now: > > > > I think there's a deeper question to answer before answering these > > questions, which is what we intend to do with large folios and zswap in > > the future. Do we intend to split them? Compress them as a large > > folio? Compress each page in a large folio separately? I can see an > > argument for choices 2 and 3, but I think choice 1 is going to be > > increasingly untenable. > > Yeah I was kinda getting the small things out of the way so that zswap > is fully folio-ized, before we think about large folios. I haven't > given it a lot of thought, but here's what I have in mind. > > Right now, I think most configs enable zswap will disable > CONFIG_THP_SWAP (otherwise all THPs will go straight to disk), so > let's assume that today we are splitting large folios before they go > to zswap (i.e. choice 1). > > What we do next depends on how the core swap intends to deal with > large folios. My understanding based on recent developments is that we > intend to swapout large folios as a whole, but I saw some discussions > about splitting all large folios before swapping them out, or leaving > them whole but swapping them out in order-0 chunks. > > I assume the rationale is that there is little benefit to keeping the > folios whole because they will most likely be freed soon anyway, but I > understand not wanting to spend time on splitting them, so swapping > them out in order-0 chunks makes some sense to me. It also dodges the > whole fragmentation issue. > > If we do either of these things in the core swap code, then I think > zswap doesn't need to do anything to support large folios. If not, > then we need to make a choice between 2 (compress large folios) & > choice 3 (compress each page separately) as you mentioned. > > Compressing large folios as a whole means that we need to decompress > them as a whole to read a single page, which I think could be very > inefficient in some cases or force us to swapin large folios. Unless > of course we end up in a world where we mostly swapin the same large > folios that we swapped out. Although there can be additional > compression savings from compressing large folios as a whole. > > Hence, I think choice 3 is the most reasonable one, at least for the > short-term. I also think this is what zram does, but I haven't > checked. Even if we all agree on this, there are still questions that > we need to answer. For example, do we allocate zswap_entry's for each > order-0 chunk right away, or do we allocate a single zswap_entry for > the entire folio, and then "split" it during swapin if we only need to > read part of the folio? > > Wondering what others think here. More thoughts that came to mind here: - Whether we go with choice 2 or 3, we may face a latency issue. Zswap compression happens synchronously in the context of reclaim, so if we start handling large folios in zswap, it may be more efficient to do it asynchronously like swap to disk. - Supporting compression of large folios depends on zsmalloc (and maybe other allocators) supporting it. There have been patches from Barry to add this support to some extent, but I didn't take a close look at those. Adding other folks from the mTHP swap discussions here in case they have other thoughts about zswap.