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 9E4E4C48BEC for ; Fri, 16 Feb 2024 09:17:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1DA838D001B; Fri, 16 Feb 2024 04:17:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 188F88D0006; Fri, 16 Feb 2024 04:17:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 078F68D001B; Fri, 16 Feb 2024 04:17:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id EBCC18D0006 for ; Fri, 16 Feb 2024 04:17:26 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B2A3AC03C3 for ; Fri, 16 Feb 2024 09:17:26 +0000 (UTC) X-FDA: 81797113692.11.7F13E6D Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by imf14.hostedemail.com (Postfix) with ESMTP id E52EE100008 for ; Fri, 16 Feb 2024 09:17:24 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Rnb8WlPL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.47 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708075044; 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=RBFR+E1NB1YNzaowT677EGkNiiRqCQR5pEHI5yk0lwA=; b=aHsdA3T5YIwPl6eFyBl1bqs92w/VAnxpm1gHhWiCKpfa5JIKA8oy4ziFdHGysrnqdliPsp IObZ8TbL/6RdTTHopRc0GNzSSFfCfm1Fu6uXBtxylN8lBEzA+Dj0OH+aKk3N+6RJxWNGZG qwSCV+/56r62NwXiROkPd5bmDRfwui4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Rnb8WlPL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.47 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708075044; a=rsa-sha256; cv=none; b=d8AYoQloCMMGj937Nx4PdTdWzJRn7rjZrqp9MZX6wR+NN7i9CfE11hEJT1h9DP4x71hTJ2 ADzg8bxNgArIDLdRiu1ASAF5o5h1GzSEJ/qFjZWXRqTz8f7QKUkhhXCmDoWQ8i+RrhFWsz 6UhUOjzYhgpyGk4NBhImawM+I+r0qtE= Received: by mail-io1-f47.google.com with SMTP id ca18e2360f4ac-7c3e01a7fe0so73697039f.2 for ; Fri, 16 Feb 2024 01:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708075044; x=1708679844; 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=RBFR+E1NB1YNzaowT677EGkNiiRqCQR5pEHI5yk0lwA=; b=Rnb8WlPL71lyyWjo6hQ1MrAhpbfRR/X10UzkVWoU2Rys+hYbZL6G2I5sB2qT3Y+HgN +rKktbhkQUC3LI0j4L/DO5xZsrQVJXQb2jcB5pYlnR4eLjk0N0PmEWq0JBO4amPJXU4v jhri18yYXDbpX/VjH9cMiuTOUaPOXFdd3Tx4oWuaF0GT+B6F5suK8irLe0Jrrz76I5Ip 42u7+4f8F3AWiRm+lvfONE63BjcGhRPoYP3rr4Zd1ton+gN/OiatqQJp6yUsvmgd4aZD 8q5Pb0bgxOXz5j9fpJa93tJtNO/7SC1Ab3gOmOTnv8AogF+r4hf7u4PJFdVIi2eEM/p1 GthQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708075044; x=1708679844; 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=RBFR+E1NB1YNzaowT677EGkNiiRqCQR5pEHI5yk0lwA=; b=oZcVyAeDsJAQ3AsUYfvQ5pJ+1qSSQeb34YMctb9NyvJJ7t9pJRiNmwf0nEemOLNhep sW9nMtE7q0QfVojUqzqH5M6dwIphA8BpKquCcBgHKbfdaWj7SZoa1mG0k4yMGQ1LVEC5 665bmb0l1K1+eWsxWjn46Th93rFur5yGRSgerb1Nydsdhx4SNH2ZG37C+V07Pm1zkCuZ 1wWe/uC4MOkagvHR2rVrihaOMzJrzqmVqcB64m8ouChnuILZkDAHUeNpFpIIHKWJ6A8X KOdBWrvWHyQRVbjpgN4pv+IY0U/9bE+E4X01BIbsMsHQzLxQQEaf55Qlp1sQ+IgeDQPO fnOQ== X-Forwarded-Encrypted: i=1; AJvYcCUgbEaeyExdEPWyDRyGNxJ7nVd3ZfmStVw9XNRKsrNxHKAnGi47Nqj/on6amDo+nr7uFBkP3kFwUJ60c0wY622NuSY= X-Gm-Message-State: AOJu0YwDOGG8JqdlwF8qKeBX+qpudI7CqcfezCRz9LpwPoLzaKNlJY5I PX/dVtZXxrww5Zwoaxgl0fiV6rz+JEcNeVtCEOFWnxvUi+ylOKBWawdL7OmLyvskniNe6DpoXDO mzDv9gd0A0qp8SotFD+/kZV4qIoo= X-Google-Smtp-Source: AGHT+IGrFahG1biGax7XYHqKpgNq6rTeugvhnejWz0bfcEXosbRal4UuMQZ31RTOB4bbb5Vn4Du/hh3fJ2si2hZaYD0= X-Received: by 2002:a5d:9c44:0:b0:7c4:4274:9c39 with SMTP id 4-20020a5d9c44000000b007c442749c39mr4804917iof.14.1708075043923; Fri, 16 Feb 2024 01:17:23 -0800 (PST) MIME-Version: 1.0 References: <20240216030539.110404-1-21cnbao@gmail.com> In-Reply-To: From: Nhat Pham Date: Fri, 16 Feb 2024 01:17:12 -0800 Message-ID: Subject: Re: [PATCH] mm: zswap: increase reject_compress_poor but not reject_compress_fail if compression returns ENOSPC To: Yosry Ahmed Cc: Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Chengming Zhou , Sergey Senozhatsky Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E52EE100008 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: dxxmhjcuenbobabq9dwxn88bfmngn8n9 X-HE-Tag: 1708075044-903525 X-HE-Meta: U2FsdGVkX19SMOKvCmQqVNN+KSS0CG7WS2WAiDuhxY/vm4mAEVXQMdlVX+kc2GHJi1kzf9yP6M6LW3+h661j51jLDJQaGZZdbYyTeFRzXUUzs62yZEsLJicQuVTzqXr6KbVV/3zDF/YCUcBd9bxzLXTtOVyJoNQlY97xnzrVLff45zyUQflyLQ47zXey+I+tPDpiYTWp2jIGZkP5cs9oe6R++e0mP5KtQoGcQttiCMjBK4/l+RwoZ0ZY8EmMGUZ1GpRraEMPjBgsjjfgnnLm5LhZAh0fIAka67nDuA6LxgksrnTywS1jrsOIroh6/6QsxgqL62wJ2C0QWGOjUcL8C54rAp5jKDN9te8pG/T/7mPApV+M+xUlB19xCiMpOp8bYJNq2voxIZaD6KjujC9ceMUgwkymU+s3jLIqd45DesyEweaxKpTzCWPjhGey66t6wx5BnrXmLC03i/47UQ37q+t98Nvvsgoxv8jPTATyHlRrAKKLU03MnmUiIYNs6sujmhLxPD7KNJBzv635FhSjKfz82C5RCrDUHy4BSCPTYT7FJcbAC+zkxfLLoQMmr9epcfJsNj3DdicBSQ+pVjWFK8iALg1q/4LUnoX07J7MkQE1nm5pW2WabqhppJz/RsNJd7zypTz8EFgDTGPN0rZWvZ6TlFD+RG+1bCZDH5MG0PIQYW2pcacIWk9H+DYnVCDQUtXB/ubbq5JmGdgJUoIQ6Tj7+Z6KHF47LBNYjZK4eG02zLwayea1elWC7F8Ejh2cqI3v/9dEwHGiiCVb28sQXKgND0TbJbYnQ21jUqwFrM4KwgBrJybs5MH97JNdkd224FkWn0NfAgBgM48lFpsB3qdK2cGFlaZy5r6jyFArqdCpBb+wxX/RAH1FYSOWAY38K6eBwrQS5iUo8GXNcxyAiXGZAZYrpt8t5ur87otb/HwjiwMu53oLwjQ/tQEnEcCzuohRRsvLWkF6nk6q5tl 8vDi7UUO 7pKelSvNwNY4CZvQJwPjtrUcJlkno96YH8UrNVukRgIkcsVxncW7StOHpmmbLm8CXMGsYrSHlDAb9iEIUZHVonbJ3Ectv4aZyvkShvBCIiX2EPQoeR4PmNSkTUc5VfQeVlwK0nJWHw/9anHPv+aocID3WArahznxOVeEGk3mOAEFoQebUWiaeLVby1u8HXbJDK2SibA2Brga4tFeHJlDLM0A80nBz7Qf+P1393PVaDQaMZ8BFP58jjGr7vyPFLVfxgez2z0FeMS9GkapQYIwRiMA1JgmnvJSNq2BAbmV22Wx69/ZFGjPgSHt7N5qGT+vtHbfVuhIMiaTdpiv7gLIkaJ7ZxAedf156VV6XiOcz/y4AXHphx0oqswCzvWPZQkIsEbY3KkoOTyxV7nURviI/H0bR0yqfErZMoT2WUQaCggJr5rQL4ubf2tE6de/oZXxBorpoaLhgjEApZ/NKP0vxj8h48iUSXDCOzbohJVOylRKZaPge83VUyYROiDuMbXemO8RNp6LgssY+CI8i7HKD7v6uCg== 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, Feb 16, 2024 at 12:23=E2=80=AFAM Yosry Ahmed wrote: > > On Fri, Feb 16, 2024 at 04:05:39PM +1300, Barry Song wrote: > > From: Barry Song > > > > My commit fc8580edbaa6 ("mm: zsmalloc: return -ENOSPC rather than -EINV= AL > > in zs_malloc while size is too large") wanted to depend on zs_malloc's > > returned ENOSPC to distinguish the case that compressed data is larger > > than the original data from normal compression cases. The commit, for > > sure, was correct and worked as expected but the code wouldn't run to > > there after commit 744e1885922a ("crypto: scomp - fix req->dst buffer > > overflow") as Chengming's this patch makes zswap_store() goto out > > immediately after the special compression case happens. So there is > > no chance to execute zs_malloc() now. We need to fix the count right > > after compressions return ENOSPC. > > > > Fixes: fc8580edbaa6 ("mm: zsmalloc: return -ENOSPC rather than -EINVAL = in zs_malloc while size is too large") > > I don't see how this is a fix for that commit. Commit fc8580edbaa6 made > sure zsmalloc returns a correct errno when the compressed size is too > large. The fact that zswap stores were failing before calling into > zsmalloc and not reporting the error correctly in debug counters is not > that commits fault. > > I think the proper fixes should be 744e1885922a if it introduced the > first scenario where -ENOSPC can be returned from scomp without handling > it properly in zswap. If -ENOSPC was a possible return value before > that, then it should be cb61dad80fdc ("zswap: export compression failure > stats"), where the counter was introduced. IIRC, the counter was introduced before the zsmalloc patch that allowed for returning -ENOSPC, as well as the patch that allowed crypto API to return -ENOSPC. I think "Fixes: 744e1885922a" would be the closest, as it introduces the -ENOSPC return value, without handling it in zswap_store(). > > > Cc: Chengming Zhou > > Cc: Nhat Pham > > Cc: Sergey Senozhatsky > > Signed-off-by: Barry Song > > --- > > mm/zswap.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/mm/zswap.c b/mm/zswap.c > > index 6319d2281020..9a21dbe8c056 100644 > > --- a/mm/zswap.c > > +++ b/mm/zswap.c > > @@ -1627,7 +1627,10 @@ bool zswap_store(struct folio *folio) > > dlen =3D acomp_ctx->req->dlen; > > > > if (ret) { > > - zswap_reject_compress_fail++; > > + if (ret =3D=3D -ENOSPC) > > + zswap_reject_compress_poor++; > > + else > > + zswap_reject_compress_fail++; > > With this diff, we have four locations in zswap_store() where we > increment zswap_reject_compress_{poor/fail}. > > How about the following instead?A > > diff --git a/mm/zswap.c b/mm/zswap.c > index 62fe307521c93..3a7e8ba7f6116 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -1059,24 +1059,16 @@ static bool zswap_compress(struct folio *folio, s= truct zswap_entry *entry) > */ > ret =3D crypto_wait_req(crypto_acomp_compress(acomp_ctx->req), &a= comp_ctx->wait); > dlen =3D acomp_ctx->req->dlen; > - if (ret) { > - zswap_reject_compress_fail++; > + if (ret) > goto unlock; > - } > > zpool =3D zswap_find_zpool(entry); > gfp =3D __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM; > if (zpool_malloc_support_movable(zpool)) > gfp |=3D __GFP_HIGHMEM | __GFP_MOVABLE; > ret =3D zpool_malloc(zpool, dlen, gfp, &handle); > - if (ret =3D=3D -ENOSPC) { > - zswap_reject_compress_poor++; > - goto unlock; > - } > - if (ret) { > - zswap_reject_alloc_fail++; > + if (ret) > goto unlock; > - } > > buf =3D zpool_map_handle(zpool, handle, ZPOOL_MM_WO); > memcpy(buf, dst, dlen); > @@ -1086,6 +1078,10 @@ static bool zswap_compress(struct folio *folio, st= ruct zswap_entry *entry) > entry->length =3D dlen; > > unlock: > + if (ret =3D=3D -ENOSPC) > + zswap_reject_compress_poor++; > + else if (ret) > + zswap_reject_alloc_fail++; I'm eyeballing this, but we have 3 debug counters possible right? zswap_reject_compress_poor, zswap_reject_compress_fail, zswap_reject_alloc_fail. I think you remove 3 incrementations (is that a word lol), and add only 2 cases here. > mutex_unlock(&acomp_ctx->mutex); > return ret =3D=3D 0; > } > > > goto put_dstmem; > > } > > > > -- > > 2.34.1 > >