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 DAEB1CDB474 for ; Tue, 17 Oct 2023 17:56:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74D5E80053; Tue, 17 Oct 2023 13:56:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FBB280045; Tue, 17 Oct 2023 13:56:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C3A980053; Tue, 17 Oct 2023 13:56:32 -0400 (EDT) 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 4C31280045 for ; Tue, 17 Oct 2023 13:56:32 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2168E1A0DF6 for ; Tue, 17 Oct 2023 17:56:32 +0000 (UTC) X-FDA: 81355708224.12.8F0C498 Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by imf23.hostedemail.com (Postfix) with ESMTP id 6791814000B for ; Tue, 17 Oct 2023 17:56:30 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NULT87pI; spf=pass (imf23.hostedemail.com: domain of cerasuolodomenico@gmail.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=cerasuolodomenico@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697565390; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MggumWsQQPnaiFXaAYuegSs4nh/E5WazHwoERvDv2z8=; b=nyN4BIBMZIxIVz0R3+7sLFahkC+shXiNA6XmvpCQzh/bkUZbzr/bJTpksDvZKqLQTEjYHY NAuHJhDxJaWsp1OZHZqTYAGTtOQOKzV0zXoHFmTMCAlYii0rtDPdAJrauK0d0HkCzSYfuV Unb1MBZlMgL0zAZ891oJenp3YGneGUM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697565390; a=rsa-sha256; cv=none; b=LlyeTrj18XZVRzKwcUy3rkH/EcpL9RycIs790JVoiTRp+PbsYKS92Gzl+X6nBiayfdblz4 ruyy5i/VnayFH1EtDwD1pn6cezSDKchbfWq7ja2yzuUtvTyndgnjU1zzWBkxOrGrqkqHqU Pk/dXVjf6LiKmTr0moYHWJVLDq7WOA4= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NULT87pI; spf=pass (imf23.hostedemail.com: domain of cerasuolodomenico@gmail.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=cerasuolodomenico@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pg1-f174.google.com with SMTP id 41be03b00d2f7-5b7f3f470a9so1042636a12.0 for ; Tue, 17 Oct 2023 10:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697565389; x=1698170189; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MggumWsQQPnaiFXaAYuegSs4nh/E5WazHwoERvDv2z8=; b=NULT87pIymDFbVpbvYlWMqXrgF/MnEwGu9VJVD6DG+AhupGz2Dv5Of5DMe3Nc8uCTi wuCIOx5iwWhOEOXjuVeaxalt2AS6j6aPl+io50hmVwtpbrxbW3NyGee+EvVqXkVBoUso Mwop3ctrHPOGXzYRp1VJ7fpNHUM743EHScbn0TRf8JL0HDGlAB65JRbzoTn0oSgZQDpW khoVJJ9Ae01QwID7PB5BLRdMbdxELMIkoqmdJNQO/+PfcaB2q5b6vT192yootA8feBKk /moW1jvlht3JezWDRx/z7dav0SfiUEEdJczLAZECS19dzct/TnMciUHuCzF6m+W/+vKh MqJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697565389; x=1698170189; h=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=MggumWsQQPnaiFXaAYuegSs4nh/E5WazHwoERvDv2z8=; b=oNR4WoHXQgIabgKgxPUGHtqpV0SAl0vuUqvTBGTkyx5k1pACox7712reHpyBcV/ysK siIv22zQJfQOquVPTMoQqBvXN9G4CLdfsiehmZmUHVbSPK8wkwyTyy7cWD6JCV5EsTZ4 j81w6Y+41Msofwmq1Q1xe7nakC2C2Gwn701yn8GUbOTvs0qhEZV3/6IHQ/j5kwT2S+h9 duHiQEbrs5qc6evyjDT35jF32r3Y94KruWgGa/5jXGT75wEMjqmf1tcwmfEAglyFZqyH AK8rw6F+8MGGQe0KVExk+ved3la/piN2/dwWuY/ZjadSGp/uOJQxpKtl4MWW4R3Y64wn j95Q== X-Gm-Message-State: AOJu0YxHO0UQY5ppLuk+2jMdYKXu/E4N8frxyg+9AXtwmX0oFX7sf4R5 C0GGlwy5XV0NT2zKevd3wFr0pdoL2bLq1/3da8c= X-Google-Smtp-Source: AGHT+IFHsRjwfI5MvZo5R16aDkdCWbrTpxi0dsjvY3nMtSffUuEssBlCIG8JREQHCnA48sF4zSoBSK0X3S6L+H8vWto= X-Received: by 2002:a17:90a:e395:b0:27d:1339:9176 with SMTP id b21-20020a17090ae39500b0027d13399176mr2930285pjz.25.1697565389101; Tue, 17 Oct 2023 10:56:29 -0700 (PDT) MIME-Version: 1.0 References: <20230919171447.2712746-1-nphamcs@gmail.com> <20230919171447.2712746-2-nphamcs@gmail.com> <21606fe5-fb9b-4d37-98ab-38c96819893b@arm.com> In-Reply-To: <21606fe5-fb9b-4d37-98ab-38c96819893b@arm.com> From: Domenico Cerasuolo Date: Tue, 17 Oct 2023 19:56:17 +0200 Message-ID: Subject: Re: [PATCH v2 1/2] zswap: make shrinking memcg-aware To: Ryan Roberts Cc: Nhat Pham , akpm@linux-foundation.org, hannes@cmpxchg.org, yosryahmed@google.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, mhocko@kernel.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Content-Type: multipart/alternative; boundary="00000000000000208f0607ed3ea7" X-Rspamd-Queue-Id: 6791814000B X-Rspam-User: X-Stat-Signature: pxdcb8juppfmqfqu7xdno8fioecwj7eq X-Rspamd-Server: rspam03 X-HE-Tag: 1697565390-122603 X-HE-Meta: U2FsdGVkX1+nbYhJGzpwplOzC5DXOVaEeoib1rWuKq3uplq4+kdvpds37Sau8kRCwL8h3IRisQqXxetUYwOcWEPwMoXyuhAkIGhRRTiq6NhpiqxVaEio34S3DB0WGoGl6qMnS3nUIIqsski/ufiLopREQk1PqBUyHOU0/dNH6W8IQUi6CcSnD+X4YKFnyRvouhSkupNih/kgTj0Bi3o4XNOwq/k8Hmi1VKlms+Gok4qrAQ4cSAIS1K+5TzWOWaS2guaANel4GoHlLwecef6xu+Kr35hRJQLcA2c+iIjDW29v7wJyu3gMFocNsUyxeE9aILW/9muqpr0EWKapARpX7c6RiA1w2lQ5LOnOVsAGyTeh4duujFHM7K8eTORfsJtV44zxbNgCBn/MyircXpPWIKGgk2io4haeBLQwaKGlNbH0t7+5ehrEBmkHN36scW8PysbMVUjRE6YkV3FCiuI5DizVKfm3eIxhMzaYMT/L57pEsY70z1EkjO/boZoShBKN6nyS0KHpceJkwl9NJdeUpRJIfxc4ECiMSxEDvq6ZhIoSC9h9KO6SUDRXCBr9PVV+wkMHtdXmI9dO0BI5GsnzvPFekyrUnQbSn3lu1OSmqnvSEsWUHCQlSc9qwHclCRfAdpKf/B4mjk/CorZonLd21x5fFVqXLjHvSiYnimKTJh+deK/TEGr7w2gEXvAcAxJkVhkLESmCn/r4fXAAL6Tc9zUTGfpnjuSG8jq6W+VjNIYCRHZ/Txg/PzOdFYwykNCuNzOaCySRGxQuNDagde/z6RCblSeeyqYLjaS18VVR8NXraJQ1JFOy/y1bdqCl3aA1axz07GJWxwGdSIthEU91e51TMQH318wlecCeeOekcXU5kXPetWNWUNsRPyjexoW+qdXSQQcafxo2+44p+BpUbpOoqy6LgjTO6OD5OoS+DsRYxMXoMveWMDn1Od4/d2Zoc4k/M8KGc/qoNmGFWys QWfYcZHI EUGqUz6dGlvhT8cXa/T+G+n8180Yi2ugofr6SFcntXWYFDqfvRRY6dyDver4gOrsLFkBwwBFjUNmpvPTt1A41EeLrYDKvJEYPWUm/d/+EahSrKea2n80KkIY8l76hnhvFi4bmOnPnlWdFnJO/QcfMMxlpRk1NdxuWiL0ELVZusOW4a9ao1XqqX1T7e6HVwKM0p61tSn+EEco3Nl9MHa68zfgkQC6Io1oZkdHizYcMiqkX5SAqPqBaKpiIjDp1l+J4JAeHWa7EZm6wTY2XB0B/JF6MvpMFGYl39ogjP72cIUzEEgMHjC6Xn8pc/oAOrLrj2SNbOFWnusmHy0WrA6Cxw09MB8JIPwOoBHQ9ufqMe2LUZkaAQBZ/peVLPb31qNUhKjtPHkXYzLpyO9a624QCAm9RVwV5bV7wsiNul6bl1HScEJUMLMgebpIUlQiFrungLYYJnbrO44tb2k/ffhxDuNoB+odJR/XFvQmWsnneSnvSADrLgXSbasOH7xkp7tj9zlipcpHJeYM3ndQcdbNms7VcAGl1JpeFd+nak93tW3amgqNVu+Dqx+uSrQ== 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: --00000000000000208f0607ed3ea7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 17, 2023 at 7:44=E2=80=AFPM Ryan Roberts = wrote: > On 19/09/2023 18:14, Nhat Pham wrote: > > From: Domenico Cerasuolo > > > > Currently, we only have a single global LRU for zswap. This makes it > > impossible to perform worload-specific shrinking - an memcg cannot > > determine which pages in the pool it owns, and often ends up writing > > pages from other memcgs. This issue has been previously observed in > > practice and mitigated by simply disabling memcg-initiated shrinking: > > > > > https://lore.kernel.org/all/20230530232435.3097106-1-nphamcs@gmail.com/T/= #u > > > > This patch fully resolves the issue by replacing the global zswap LRU > > with memcg- and NUMA-specific LRUs, and modify the reclaim logic: > > > > a) When a store attempt hits an memcg limit, it now triggers a > > synchronous reclaim attempt that, if successful, allows the new > > hotter page to be accepted by zswap. > > b) If the store attempt instead hits the global zswap limit, it will > > trigger an asynchronous reclaim attempt, in which an memcg is > > selected for reclaim in a round-robin-like fashion. > > > > Signed-off-by: Domenico Cerasuolo > > Co-developed-by: Nhat Pham > > Signed-off-by: Nhat Pham > > --- > > include/linux/list_lru.h | 39 +++++++ > > include/linux/memcontrol.h | 5 + > > include/linux/zswap.h | 9 ++ > > mm/list_lru.c | 46 ++++++-- > > mm/swap_state.c | 19 ++++ > > mm/zswap.c | 221 +++++++++++++++++++++++++++++-------- > > 6 files changed, 287 insertions(+), 52 deletions(-) > > > > [...] > > > @@ -1199,8 +1272,10 @@ bool zswap_store(struct folio *folio) > > struct scatterlist input, output; > > struct crypto_acomp_ctx *acomp_ctx; > > struct obj_cgroup *objcg =3D NULL; > > + struct mem_cgroup *memcg =3D NULL; > > struct zswap_pool *pool; > > struct zpool *zpool; > > + int lru_alloc_ret; > > unsigned int dlen =3D PAGE_SIZE; > > unsigned long handle, value; > > char *buf; > > @@ -1218,14 +1293,15 @@ bool zswap_store(struct folio *folio) > > if (!zswap_enabled || !tree) > > return false; > > > > - /* > > - * XXX: zswap reclaim does not work with cgroups yet. Without a > > - * cgroup-aware entry LRU, we will push out entries system-wide > based on > > - * local cgroup limits. > > - */ > > objcg =3D get_obj_cgroup_from_folio(folio); > > - if (objcg && !obj_cgroup_may_zswap(objcg)) > > - goto reject; > > + if (objcg && !obj_cgroup_may_zswap(objcg)) { > > + memcg =3D get_mem_cgroup_from_objcg(objcg); > > + if (shrink_memcg(memcg)) { > > + mem_cgroup_put(memcg); > > + goto reject; > > + } > > + mem_cgroup_put(memcg); > > + } > > > > /* reclaim space if needed */ > > if (zswap_is_full()) { > > @@ -1240,7 +1316,11 @@ bool zswap_store(struct folio *folio) > > else > > zswap_pool_reached_full =3D false; > > } > > - > > + pool =3D zswap_pool_current_get(); > > + if (!pool) { > > + ret =3D -EINVAL; > > + goto reject; > > + } > > > Hi, I'm working to add support for large folios within zswap, and noticed > this > piece of code added by this change. I don't see any corresponding put. > Have I > missed some detail or is there a bug here? > > > > /* allocate entry */ > > entry =3D zswap_entry_cache_alloc(GFP_KERNEL); > > if (!entry) { > > @@ -1256,6 +1336,7 @@ bool zswap_store(struct folio *folio) > > entry->length =3D 0; > > entry->value =3D value; > > atomic_inc(&zswap_same_filled_pages); > > + zswap_pool_put(pool); > > I see you put it in this error path, but after that, there is no further > mention. > > > goto insert_entry; > > } > > kunmap_atomic(src); > > @@ -1264,6 +1345,15 @@ bool zswap_store(struct folio *folio) > > if (!zswap_non_same_filled_pages_enabled) > > goto freepage; > > > > + if (objcg) { > > + memcg =3D get_mem_cgroup_from_objcg(objcg); > > + lru_alloc_ret =3D memcg_list_lru_alloc(memcg, > &pool->list_lru, GFP_KERNEL); > > + mem_cgroup_put(memcg); > > + > > + if (lru_alloc_ret) > > + goto freepage; > > + } > > + > > /* if entry is successfully added, it keeps the reference */ > > entry->pool =3D zswap_pool_current_get(); > > The entry takes it's reference to the pool here. > > Thanks, > Ryan > Thanks Ryan, I think you're right. Coincidentally, we're about to send a ne= w version of the series, and will make sure to address this too. --00000000000000208f0607ed3ea7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 17, 2023 at 7:44=E2=80=AF= PM Ryan Roberts <ryan.roberts@ar= m.com> wrote:
On 19/09/2023 18:14, Nhat Pham wrote:
> From: Domenico Cerasuolo <cerasuolodomenico@gmail.com>
>
> Currently, we only have a single global LRU for zswap. This makes it > impossible to perform worload-specific shrinking - an memcg cannot
> determine which pages in the pool it owns, and often ends up writing > pages from other memcgs. This issue has been previously observed in > practice and mitigated by simply disabling memcg-initiated shrinking:<= br> >
> https://lore.kernel.= org/all/20230530232435.3097106-1-nphamcs@gmail.com/T/#u
>
> This patch fully resolves the issue by replacing the global zswap LRU<= br> > with memcg- and NUMA-specific LRUs, and modify the reclaim logic:
>
> a) When a store attempt hits an memcg limit, it now triggers a
>=C2=A0 =C2=A0 synchronous reclaim attempt that, if successful, allows t= he new
>=C2=A0 =C2=A0 hotter page to be accepted by zswap.
> b) If the store attempt instead hits the global zswap limit, it will >=C2=A0 =C2=A0 trigger an asynchronous reclaim attempt, in which an memc= g is
>=C2=A0 =C2=A0 selected for reclaim in a round-robin-like fashion.
>
> Signed-off-by: Domenico Cerasuolo <cerasuolodomenico@gmail.com>
> Co-developed-by: Nhat Pham <nphamcs@gmail.com>
> Signed-off-by: Nhat Pham <nphamcs@gmail.com>
> ---
>=C2=A0 include/linux/list_lru.h=C2=A0 =C2=A0|=C2=A0 39 +++++++
>=C2=A0 include/linux/memcontrol.h |=C2=A0 =C2=A05 +
>=C2=A0 include/linux/zswap.h=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A09 ++
>=C2=A0 mm/list_lru.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 46 ++++++--
>=C2=A0 mm/swap_state.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0= 19 ++++
>=C2=A0 mm/zswap.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| 221 +++++++++++++++++++++++++++++--------
>=C2=A0 6 files changed, 287 insertions(+), 52 deletions(-)
>

[...]

> @@ -1199,8 +1272,10 @@ bool zswap_store(struct folio *folio)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0struct scatterlist input, output;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0struct crypto_acomp_ctx *acomp_ctx;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0struct obj_cgroup *objcg =3D NULL;
> +=C2=A0 =C2=A0 =C2=A0struct mem_cgroup *memcg =3D NULL;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0struct zswap_pool *pool;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0struct zpool *zpool;
> +=C2=A0 =C2=A0 =C2=A0int lru_alloc_ret;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned int dlen =3D PAGE_SIZE;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned long handle, value;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0char *buf;
> @@ -1218,14 +1293,15 @@ bool zswap_store(struct folio *folio)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!zswap_enabled || !tree)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return false; >=C2=A0
> -=C2=A0 =C2=A0 =C2=A0/*
> -=C2=A0 =C2=A0 =C2=A0 * XXX: zswap reclaim does not work with cgroups = yet. Without a
> -=C2=A0 =C2=A0 =C2=A0 * cgroup-aware entry LRU, we will push out entri= es system-wide based on
> -=C2=A0 =C2=A0 =C2=A0 * local cgroup limits.
> -=C2=A0 =C2=A0 =C2=A0 */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0objcg =3D get_obj_cgroup_from_folio(folio);<= br> > -=C2=A0 =C2=A0 =C2=A0if (objcg && !obj_cgroup_may_zswap(objcg)= )
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto reject;
> +=C2=A0 =C2=A0 =C2=A0if (objcg && !obj_cgroup_may_zswap(objcg)= ) {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0memcg =3D get_mem_cgr= oup_from_objcg(objcg);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (shrink_memcg(memc= g)) {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0mem_cgroup_put(memcg);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0goto reject;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mem_cgroup_put(memcg)= ;
> +=C2=A0 =C2=A0 =C2=A0}
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/* reclaim space if needed */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (zswap_is_full()) {
> @@ -1240,7 +1316,11 @@ bool zswap_store(struct folio *folio)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0zswap_pool_reached_full =3D false;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> -
> +=C2=A0 =C2=A0 =C2=A0pool =3D zswap_pool_current_get();
> +=C2=A0 =C2=A0 =C2=A0if (!pool) {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ret =3D -EINVAL;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto reject;
> +=C2=A0 =C2=A0 =C2=A0}


Hi, I'm working to add support for large folios within zswap, and notic= ed this
piece of code added by this change. I don't see any corresponding put. = Have I
missed some detail or is there a bug here?


>=C2=A0 =C2=A0 =C2=A0 =C2=A0/* allocate entry */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0entry =3D zswap_entry_cache_alloc(GFP_KERNEL= );
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!entry) {
> @@ -1256,6 +1336,7 @@ bool zswap_store(struct folio *folio)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0entry->length =3D 0;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0entry->value =3D value;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0atomic_inc(&zswap_same_filled_pages);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0zswap_pool_put(pool);

I see you put it in this error path, but after that, there is no further me= ntion.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0goto insert_entry;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kunmap_atomic(sr= c);
> @@ -1264,6 +1345,15 @@ bool zswap_store(struct folio *folio)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!zswap_non_same_filled_pages_enabled) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto freepage; >=C2=A0
> +=C2=A0 =C2=A0 =C2=A0if (objcg) {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0memcg =3D get_mem_cgr= oup_from_objcg(objcg);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lru_alloc_ret =3D mem= cg_list_lru_alloc(memcg, &pool->list_lru, GFP_KERNEL);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mem_cgroup_put(memcg)= ;
> +
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (lru_alloc_ret) > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0goto freepage;
> +=C2=A0 =C2=A0 =C2=A0}
> +
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/* if entry is successfully added, it keeps = the reference */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0entry->pool =3D zswap_pool_current_get();=

The entry takes it's reference to the pool here.

Thanks,
Ryan

Thanks Ryan, I think you're ri= ght. Coincidentally, we're about to send a new
version of the seri= es, and will make sure to address this too.
--00000000000000208f0607ed3ea7--