mm: zswap: increase reject_compress_poor but not reject_compress_fail if compression returns ENOSPC
Message ID | 20240216030539.110404-1-21cnbao@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-67984-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:c619:b0:108:e6aa:91d0 with SMTP id hn25csp266496dyb; Thu, 15 Feb 2024 19:06:39 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXvfwz18F+tLWnqKQSzdX1kIjhBUQ4XPilE8kz7VqIIAuJQxkRt57q2HQAJCW76jFXUO5wPhQnUFXLAreMYAmTjWQXdZA== X-Google-Smtp-Source: AGHT+IGOSZb17PIH+wHXpIi8PG8mNvS9ELpV/++PAie1OjemEDaWRAsuxjxJ4NW9fQNAfdLPff2z X-Received: by 2002:a17:902:e547:b0:1da:237e:4754 with SMTP id n7-20020a170902e54700b001da237e4754mr4630431plf.8.1708052799049; Thu, 15 Feb 2024 19:06:39 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708052799; cv=pass; d=google.com; s=arc-20160816; b=ablbCIOFnc6pp/gonpozjnZ1IDp9Ib2XEblCRV1iP3LewXUh4rgcwV3feqBA8BH3yC 14RvYRLCJT7+dnSLX63j7HWXPssa9a23WOtHUl19YWWPF1jjM83wFBKK4kMNTrlXVXWY yvsev5jDDqGH2iyjJJvNPOMpATsF5Xm5Y986XFpBx8ty1/OyMWtoMwyGVdWfROeB1/1v 4zOsuPtjW8esMWk0VncDH2PBu/ZgY8ca7U3V8rTrI37RM0nXdzMTf+Y9u6aexlqe2JaU M5q9ne+ioxgmRw4/DB16WZRX5MPSjoecWQlJvuRzqcNnQA95j6DI+Z62hbOVYVbwDZKj bMxA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=I7PSTWVmaYWH42bBGC9KPcBO882rqj+Igdtxrd/WR4k=; fh=bJKv2TR39b5jGs2ZrGRxNWo52A08nT3W2P4FuNMxiJA=; b=DWiN+Ojw62chstNdO0TSJYnPv5zJXgR1vjkra1xwSv5l0iUw4nv1BEd2W4JYEQ0KiT MXnUWix9rYFGvTuJq/qAuYzqNIApA+yS5ly2PfjiljKAiV0/imO8al2AVIoAdZT+Jo/T v7M86G4SOsajVi1IV8UtlYbbdXuFnz4mgXBcu0IuxPa+tDAUlz98+mKaGaXbmjyg2XNT YeZSZd9T4Lca22+GSTkZhBnPNd2dDYFP5GaEp5NhmWHX41m6sm4VON331qebUyeeiAd5 XL5OxfhHvJ4+QcgUIFXSmUEP1kk4AQUBdYjG3GfqXgxASX/Kq71hUBF9sBFcXKBgeWoN +R+w==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HX0IYrqJ; arc=pass (i=1 spf=pass spfdomain=gmail.com dkim=pass dkdomain=gmail.com dmarc=pass fromdomain=gmail.com); spf=pass (google.com: domain of linux-kernel+bounces-67984-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-67984-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id lw7-20020a1709032ac700b001d098bf0df8si2262134plb.612.2024.02.15.19.06.38 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 19:06:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-67984-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HX0IYrqJ; arc=pass (i=1 spf=pass spfdomain=gmail.com dkim=pass dkdomain=gmail.com dmarc=pass fromdomain=gmail.com); spf=pass (google.com: domain of linux-kernel+bounces-67984-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-67984-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id F2C5FB22F5E for <ouuuleilei@gmail.com>; Fri, 16 Feb 2024 03:06:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EA4F2101F2; Fri, 16 Feb 2024 03:06:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HX0IYrqJ" Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 02327FBE5 for <linux-kernel@vger.kernel.org>; Fri, 16 Feb 2024 03:05:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708052758; cv=none; b=QFtIsyalXAxhTs/8ds/VDL6SHHnTAqK82HbbqyMfxzxMbEZc1qeUHp6ZI8pmU5WKzgtrXaabz6gMuwdxhHVeEkuenZnAoSffR5Bw173n5WLmzpNCLf3anuX3eYkbKgYcpUkSd3XHWHmrP+A6xQ1NZG3WG29MGckmRyN+PVlmZHI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708052758; c=relaxed/simple; bh=8dqe4bC0acMyEVaUnbbYMP4IvFDUFr77j4xc05dO4WU=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=Lf75XfL/PXhjBOJqyZPgHYSCyqwztqgJTSePdYmfGa7UE7iLCO9ysTQ775SViAonJES4N+RsBgGCrjqhpcYPebveGZVIWpi6sUtippz+0bXEZl8jonJVqNLOnhK8D8K/tySYcRLIYgi7ok7xn4eTgl+i0/0RywJ6EsgWaghlQZQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=HX0IYrqJ; arc=none smtp.client-ip=209.85.210.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-6e104196e6eso1661996b3a.0 for <linux-kernel@vger.kernel.org>; Thu, 15 Feb 2024 19:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708052756; x=1708657556; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=I7PSTWVmaYWH42bBGC9KPcBO882rqj+Igdtxrd/WR4k=; b=HX0IYrqJr+6dhxkxlZUEZ0tNL9F8cn/SZ79MKBIShu3jIOrx4EgOBW3qb1PufNJN8/ 2e/c4jaAxyKjpDqUJzZdj+jF8dx+9SW0ZRhJwdDQT0wBmjAiWF3hXFh9l8F8mmvZJhF1 /Bt4EmUqQ0FlzPcgQ8wtCH9PpmcBO/u5mgKmcy5fXDpPzja+K3YjdukBm2GnAxKN+sxQ L2sVfW8L3YMfGQtHNP1LUVkWVKA8mwuJI9yP5xgbIVsl7zS9f6LABiPngvXXvAuIlzTI K/HXm8dAAA9pSTBJAVGrYQEIkGtF7CB6wGGnKAo/hXcWVTUuiOI4C5e9M00+sTjUqb9t wHpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708052756; x=1708657556; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=I7PSTWVmaYWH42bBGC9KPcBO882rqj+Igdtxrd/WR4k=; b=O3s7Sie7FaznULonOfgCR6iUR4gpvAIaUWKmzqE+pZk2VKqqjxlDLTt1pIq/ZUzhJt /KP+TGKYITwSDbApDw4ir1TTu9hvwvGtvWzDNRhdbEEvfn+P16aIUHZXlHckRmbATuMd bJTxycI2x9XEKo4dylWx3jXxc9qQ1oenFkAi0/xPeBqueN4L4UhLmldrR6Bv+fU/J0cA oTFRZAWXMQTJvX2LpcjocD3fhyRTZzkZ9Do4lHHEfRYFK3m+0jTY29U7wUUdLnI+HyZ/ 6iz36M8Z2wD6hsJT9v2JFYIQsK8KIo1RW9AqLpojNwobrlSvc+MCcZ55iw/ZVy1njePd iRQQ== X-Gm-Message-State: AOJu0Yyw/o0sSPsXaVGxdMNOOFinzH0fmsiwQibxEIHFJAI3ezUk8w8/ /rt6AcUVO1i/c3YvyvYSyv2jyTI+82Rk3kFDpXrQRR0B1f3QVpXf X-Received: by 2002:a05:6a00:22c9:b0:6e0:fb6e:124e with SMTP id f9-20020a056a0022c900b006e0fb6e124emr4794443pfj.26.1708052756168; Thu, 15 Feb 2024 19:05:56 -0800 (PST) Received: from barry-desktop.hub ([2407:7000:8942:5500:f28b:3925:777f:45d4]) by smtp.gmail.com with ESMTPSA id lc25-20020a056a004f5900b006e0eece1ca4sm2017757pfb.4.2024.02.15.19.05.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 19:05:55 -0800 (PST) From: Barry Song <21cnbao@gmail.com> To: akpm@linux-foundation.org, hannes@cmpxchg.org, linux-mm@kvack.org, yosryahmed@google.com Cc: linux-kernel@vger.kernel.org, Barry Song <v-songbaohua@oppo.com>, Chengming Zhou <zhouchengming@bytedance.com>, Nhat Pham <nphamcs@gmail.com>, Sergey Senozhatsky <senozhatsky@chromium.org> Subject: [PATCH] mm: zswap: increase reject_compress_poor but not reject_compress_fail if compression returns ENOSPC Date: Fri, 16 Feb 2024 16:05:39 +1300 Message-Id: <20240216030539.110404-1-21cnbao@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791023172063122165 X-GMAIL-MSGID: 1791023172063122165 |
Series |
mm: zswap: increase reject_compress_poor but not reject_compress_fail if compression returns ENOSPC
|
|
Commit Message
Barry Song
Feb. 16, 2024, 3:05 a.m. UTC
From: Barry Song <v-songbaohua@oppo.com> My commit fc8580edbaa6 ("mm: zsmalloc: return -ENOSPC rather than -EINVAL 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") Cc: Chengming Zhou <zhouchengming@bytedance.com> Cc: Nhat Pham <nphamcs@gmail.com> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by: Barry Song <v-songbaohua@oppo.com> --- mm/zswap.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Comments
On Fri, Feb 16, 2024 at 04:05:39PM +1300, Barry Song wrote: > From: Barry Song <v-songbaohua@oppo.com> > > My commit fc8580edbaa6 ("mm: zsmalloc: return -ENOSPC rather than -EINVAL > 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. > Cc: Chengming Zhou <zhouchengming@bytedance.com> > Cc: Nhat Pham <nphamcs@gmail.com> > Cc: Sergey Senozhatsky <senozhatsky@chromium.org> > Signed-off-by: Barry Song <v-songbaohua@oppo.com> > --- > 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 = acomp_ctx->req->dlen; > > if (ret) { > - zswap_reject_compress_fail++; > + if (ret == -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, struct zswap_entry *entry) */ ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req), &acomp_ctx->wait); dlen = acomp_ctx->req->dlen; - if (ret) { - zswap_reject_compress_fail++; + if (ret) goto unlock; - } zpool = zswap_find_zpool(entry); gfp = __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM; if (zpool_malloc_support_movable(zpool)) gfp |= __GFP_HIGHMEM | __GFP_MOVABLE; ret = zpool_malloc(zpool, dlen, gfp, &handle); - if (ret == -ENOSPC) { - zswap_reject_compress_poor++; - goto unlock; - } - if (ret) { - zswap_reject_alloc_fail++; + if (ret) goto unlock; - } buf = zpool_map_handle(zpool, handle, ZPOOL_MM_WO); memcpy(buf, dst, dlen); @@ -1086,6 +1078,10 @@ static bool zswap_compress(struct folio *folio, struct zswap_entry *entry) entry->length = dlen; unlock: + if (ret == -ENOSPC) + zswap_reject_compress_poor++; + else if (ret) + zswap_reject_alloc_fail++; mutex_unlock(&acomp_ctx->mutex); return ret == 0; } > goto put_dstmem; > } > > -- > 2.34.1 >
On 2024/2/16 16:23, Yosry Ahmed wrote: > On Fri, Feb 16, 2024 at 04:05:39PM +1300, Barry Song wrote: >> From: Barry Song <v-songbaohua@oppo.com> >> >> My commit fc8580edbaa6 ("mm: zsmalloc: return -ENOSPC rather than -EINVAL >> 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. Right, 744e1885922a maybe a better fixes target. > >> Cc: Chengming Zhou <zhouchengming@bytedance.com> >> Cc: Nhat Pham <nphamcs@gmail.com> >> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> >> Signed-off-by: Barry Song <v-songbaohua@oppo.com> >> --- >> 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 = acomp_ctx->req->dlen; >> >> if (ret) { >> - zswap_reject_compress_fail++; >> + if (ret == -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, struct zswap_entry *entry) > */ > ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req), &acomp_ctx->wait); > dlen = acomp_ctx->req->dlen; > - if (ret) { > - zswap_reject_compress_fail++; > + if (ret) > goto unlock; > - } > > zpool = zswap_find_zpool(entry); > gfp = __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM; > if (zpool_malloc_support_movable(zpool)) > gfp |= __GFP_HIGHMEM | __GFP_MOVABLE; > ret = zpool_malloc(zpool, dlen, gfp, &handle); > - if (ret == -ENOSPC) { > - zswap_reject_compress_poor++; > - goto unlock; > - } > - if (ret) { > - zswap_reject_alloc_fail++; > + if (ret) > goto unlock; > - } > > buf = zpool_map_handle(zpool, handle, ZPOOL_MM_WO); > memcpy(buf, dst, dlen); > @@ -1086,6 +1078,10 @@ static bool zswap_compress(struct folio *folio, struct zswap_entry *entry) > entry->length = dlen; > > unlock: > + if (ret == -ENOSPC) > + zswap_reject_compress_poor++; > + else if (ret) > + zswap_reject_alloc_fail++; Here have two cases: zswap_reject_compress_fail, zswap_reject_alloc_fail. > mutex_unlock(&acomp_ctx->mutex); > return ret == 0; > } > >> goto put_dstmem; >> } >> >> -- >> 2.34.1 >>
On Fri, Feb 16, 2024 at 5:07 PM Chengming Zhou <zhouchengming@bytedance.com> wrote: > > On 2024/2/16 16:23, Yosry Ahmed wrote: > > On Fri, Feb 16, 2024 at 04:05:39PM +1300, Barry Song wrote: > >> From: Barry Song <v-songbaohua@oppo.com> > >> > >> My commit fc8580edbaa6 ("mm: zsmalloc: return -ENOSPC rather than -EINVAL > >> 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. > > Hi Yosry, Chengming, Thanks for your quick responses. > > 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. > > Right, 744e1885922a maybe a better fixes target. I agree 744e1885922a is a better fixes target. > > > > >> Cc: Chengming Zhou <zhouchengming@bytedance.com> > >> Cc: Nhat Pham <nphamcs@gmail.com> > >> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> > >> Signed-off-by: Barry Song <v-songbaohua@oppo.com> > >> --- > >> 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 = acomp_ctx->req->dlen; > >> > >> if (ret) { > >> - zswap_reject_compress_fail++; > >> + if (ret == -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, struct zswap_entry *entry) > > */ > > ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req), &acomp_ctx->wait); > > dlen = acomp_ctx->req->dlen; > > - if (ret) { > > - zswap_reject_compress_fail++; > > + if (ret) > > goto unlock; > > - } > > > > zpool = zswap_find_zpool(entry); > > gfp = __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM; > > if (zpool_malloc_support_movable(zpool)) > > gfp |= __GFP_HIGHMEM | __GFP_MOVABLE; > > ret = zpool_malloc(zpool, dlen, gfp, &handle); > > - if (ret == -ENOSPC) { > > - zswap_reject_compress_poor++; > > - goto unlock; > > - } > > - if (ret) { > > - zswap_reject_alloc_fail++; > > + if (ret) > > goto unlock; > > - } > > > > buf = zpool_map_handle(zpool, handle, ZPOOL_MM_WO); > > memcpy(buf, dst, dlen); > > @@ -1086,6 +1078,10 @@ static bool zswap_compress(struct folio *folio, struct zswap_entry *entry) > > entry->length = dlen; > > > > unlock: > > + if (ret == -ENOSPC) > > + zswap_reject_compress_poor++; > > + else if (ret) > > + zswap_reject_alloc_fail++; > > Here have two cases: zswap_reject_compress_fail, zswap_reject_alloc_fail. Is it safe to differentiate these two cases by checking ret == -ENOMEM ? otherwise, it seems the original patch still makes more sense? > > > mutex_unlock(&acomp_ctx->mutex); > > return ret == 0; > > } > > > >> goto put_dstmem; > >> } > >> > >> -- > >> 2.34.1 > >> Thanks Barry
On Fri, Feb 16, 2024 at 12:23 AM Yosry Ahmed <yosryahmed@google.com> wrote: > > On Fri, Feb 16, 2024 at 04:05:39PM +1300, Barry Song wrote: > > From: Barry Song <v-songbaohua@oppo.com> > > > > My commit fc8580edbaa6 ("mm: zsmalloc: return -ENOSPC rather than -EINVAL > > 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 <zhouchengming@bytedance.com> > > Cc: Nhat Pham <nphamcs@gmail.com> > > Cc: Sergey Senozhatsky <senozhatsky@chromium.org> > > Signed-off-by: Barry Song <v-songbaohua@oppo.com> > > --- > > 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 = acomp_ctx->req->dlen; > > > > if (ret) { > > - zswap_reject_compress_fail++; > > + if (ret == -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, struct zswap_entry *entry) > */ > ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req), &acomp_ctx->wait); > dlen = acomp_ctx->req->dlen; > - if (ret) { > - zswap_reject_compress_fail++; > + if (ret) > goto unlock; > - } > > zpool = zswap_find_zpool(entry); > gfp = __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM; > if (zpool_malloc_support_movable(zpool)) > gfp |= __GFP_HIGHMEM | __GFP_MOVABLE; > ret = zpool_malloc(zpool, dlen, gfp, &handle); > - if (ret == -ENOSPC) { > - zswap_reject_compress_poor++; > - goto unlock; > - } > - if (ret) { > - zswap_reject_alloc_fail++; > + if (ret) > goto unlock; > - } > > buf = zpool_map_handle(zpool, handle, ZPOOL_MM_WO); > memcpy(buf, dst, dlen); > @@ -1086,6 +1078,10 @@ static bool zswap_compress(struct folio *folio, struct zswap_entry *entry) > entry->length = dlen; > > unlock: > + if (ret == -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 == 0; > } > > > goto put_dstmem; > > } > > > > -- > > 2.34.1 > >
> > >> 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 = acomp_ctx->req->dlen; > > >> > > >> if (ret) { > > >> - zswap_reject_compress_fail++; > > >> + if (ret == -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, struct zswap_entry *entry) > > > */ > > > ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req), &acomp_ctx->wait); > > > dlen = acomp_ctx->req->dlen; > > > - if (ret) { > > > - zswap_reject_compress_fail++; > > > + if (ret) > > > goto unlock; > > > - } > > > > > > zpool = zswap_find_zpool(entry); > > > gfp = __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM; > > > if (zpool_malloc_support_movable(zpool)) > > > gfp |= __GFP_HIGHMEM | __GFP_MOVABLE; > > > ret = zpool_malloc(zpool, dlen, gfp, &handle); > > > - if (ret == -ENOSPC) { > > > - zswap_reject_compress_poor++; > > > - goto unlock; > > > - } > > > - if (ret) { > > > - zswap_reject_alloc_fail++; > > > + if (ret) > > > goto unlock; > > > - } > > > > > > buf = zpool_map_handle(zpool, handle, ZPOOL_MM_WO); > > > memcpy(buf, dst, dlen); > > > @@ -1086,6 +1078,10 @@ static bool zswap_compress(struct folio *folio, struct zswap_entry *entry) > > > entry->length = dlen; > > > > > > unlock: > > > + if (ret == -ENOSPC) > > > + zswap_reject_compress_poor++; > > > + else if (ret) > > > + zswap_reject_alloc_fail++; > > > > Here have two cases: zswap_reject_compress_fail, zswap_reject_alloc_fail. Ah brain fart, sorry. > > Is it safe to differentiate these two cases by checking ret == -ENOMEM ? > otherwise, it seems the original patch still makes more sense? I don't think it is in all cases, some allocators return other error codes. It seems unlikely that we'll get any of them, but it can be missed in the future. How about we use different return codes to differentiate failures, and still centralize the counters handling. Something like the following (ideally that one is not a brain fart): diff --git a/mm/zswap.c b/mm/zswap.c index 62fe307521c93..20ba25b7601a7 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1021,12 +1021,12 @@ static bool zswap_compress(struct folio *folio, struct zswap_entry *entry) { struct crypto_acomp_ctx *acomp_ctx; struct scatterlist input, output; + int comp_ret = 0, alloc_ret = 0; unsigned int dlen = PAGE_SIZE; unsigned long handle; struct zpool *zpool; char *buf; gfp_t gfp; - int ret; u8 *dst; acomp_ctx = raw_cpu_ptr(entry->pool->acomp_ctx); @@ -1057,26 +1057,18 @@ static bool zswap_compress(struct folio *folio, struct zswap_entry *entry) * but in different threads running on different cpu, we have different * acomp instance, so multiple threads can do (de)compression in parallel. */ - ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req), &acomp_ctx->wait); + comp_ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req), &acomp_ctx->wait); dlen = acomp_ctx->req->dlen; - if (ret) { - zswap_reject_compress_fail++; + if (comp_ret) goto unlock; - } zpool = zswap_find_zpool(entry); gfp = __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM; if (zpool_malloc_support_movable(zpool)) gfp |= __GFP_HIGHMEM | __GFP_MOVABLE; - ret = zpool_malloc(zpool, dlen, gfp, &handle); - if (ret == -ENOSPC) { - zswap_reject_compress_poor++; - goto unlock; - } - if (ret) { - zswap_reject_alloc_fail++; + alloc_ret = zpool_malloc(zpool, dlen, gfp, &handle); + if (alloc_ret) goto unlock; - } buf = zpool_map_handle(zpool, handle, ZPOOL_MM_WO); memcpy(buf, dst, dlen); @@ -1086,6 +1078,13 @@ static bool zswap_compress(struct folio *folio, struct zswap_entry *entry) entry->length = dlen; unlock: + if (comp_ret == -ENOSPC || alloc_ret == -ENOSPC) + zswap_reject_compress_poor++; + else if (comp_ret) + zswap_reject_compress_fail++; + else if (alloc_ret) + zswap_reject_alloc_fail++; + mutex_unlock(&acomp_ctx->mutex); return ret == 0; } > > > > > > mutex_unlock(&acomp_ctx->mutex); > > > return ret == 0; > > > } > > > > > >> goto put_dstmem; > > >> } > > >> > > >> -- > > >> 2.34.1 > > >> > > Thanks > Barry
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 = acomp_ctx->req->dlen; if (ret) { - zswap_reject_compress_fail++; + if (ret == -ENOSPC) + zswap_reject_compress_poor++; + else + zswap_reject_compress_fail++; goto put_dstmem; }