From nobody Sat Feb 7 12:19:31 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A76FC7EE24 for ; Tue, 30 May 2023 22:24:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233716AbjE3WYp (ORCPT ); Tue, 30 May 2023 18:24:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229945AbjE3WYn (ORCPT ); Tue, 30 May 2023 18:24:43 -0400 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A04BE5 for ; Tue, 30 May 2023 15:24:42 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-64d341bdedcso3693229b3a.3 for ; Tue, 30 May 2023 15:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685485481; x=1688077481; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=G/1SowEewql6UJanqoqPfCeIbhtfTWUbi0a35Y9vIrs=; b=WnGpKbOV8lvKv65POyTi6fFpPciJnn2J218zZF6h2JBge30QnWdNUvnzUrtIt8UgnZ 2eW1iZOQ2Tt2wXfrF2sy9wyLOHpdabbOEbVJDs3E75P65V7vvOuV1Ux5MwkFcjkLY7Xz Bu7uKz5n+vefnTqjV1nadY4GfOrsQ0Uw+HjVXvDl4I0StS513zWcuXQq5eVL+/MlwMXu 8F2l0wObfSk2UsB5Dk9tPoBRFXwVKzqv8ZWdz8aH6tf7AsfQAloacKm3lmKE+Xj2uWJv Govc/74/GHTR45rriTat2bDrmCYoFbabV+xQ/5N+eZDgjJPHDFFE+TLtd0w9u57QaQJX anMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685485481; x=1688077481; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=G/1SowEewql6UJanqoqPfCeIbhtfTWUbi0a35Y9vIrs=; b=Wi4vTEZqfoUospKaG69FJmR3EjGWeXsdkmZxIyQrmMpJH478qxc4/mo7ZZHhXclpEJ izadwWMA6T9lE4peiJLS/2hZMVTO3yZ2Eg8qAgBGqxJ7Lma70g3F2Bimd7wQ04jgCoXN BQJGxc56MWCTok3Rhl5RVo7nyJs8Likg99niCTFRwL32+2vheCVDMYH81aD1y1nJ5/ES OwCllHzYwnpwFE8+TwriiJlEDaUfXA6qZjNbKowh04ENONpZGqnB14yeiP+QubQa7Faw xjTcDooOs45Tr1HIKpDX1YmegThv29PfuP3K4HzG1DRS5jNOAt32Ph115ANxA4rcD4V1 20jA== X-Gm-Message-State: AC+VfDzx+vXr5A+Qa9m/vnyTdOoPIQfJYBEFxIrJWMKLhK+Ucjp2AX/r 13xEEis4Em29RxaHNT7uPik= X-Google-Smtp-Source: ACHHUZ7o0vAxUBMoiek8AqoGTNtUZ009NsT2LcERUfQxIOYsAOkRZBMLNu4fP80xpI5LAqDbmuIFpQ== X-Received: by 2002:a17:902:e74f:b0:1b0:2658:db00 with SMTP id p15-20020a170902e74f00b001b02658db00mr4629006plf.31.1685485481413; Tue, 30 May 2023 15:24:41 -0700 (PDT) Received: from localhost (fwdproxy-prn-005.fbsv.net. [2a03:2880:ff:5::face:b00c]) by smtp.gmail.com with ESMTPSA id t5-20020a170902e84500b001a212a93295sm1719203plg.189.2023.05.30.15.24.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 May 2023 15:24:41 -0700 (PDT) From: Nhat Pham To: akpm@linux-foundation.org Cc: hannes@cmpxchg.org, cerasuolodomenico@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, yosryahmed@google.com, kernel-team@meta.com Subject: [PATCH] zswap: do not shrink if cgroup may not zswap Date: Tue, 30 May 2023 15:24:40 -0700 Message-Id: <20230530222440.2777700-1-nphamcs@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Before storing a page, zswap first checks if the number of stored pages exceeds the limit specified by memory.zswap.max, for each cgroup in the hierarchy. If this limit is reached or exceeded, then zswap shrinking is triggered and short-circuits the store attempt. However, since the zswap's LRU is not memcg-aware, this can create the following pathological behavior: the cgroup whose zswap limit is reached will evict pages from other cgroups continually, without lowering its own zswap usage. This means the shrinking will continue until the need for swap ceases or the pool becomes empty. As a result of this, we observe a disproportionate amount of zswap writeback and a perpetually small zswap pool in our experiments, even though the pool limit is never hit. This patch fixes the issue by rejecting zswap store attempt without shrinking the pool when obj_cgroup_may_zswap() returns false. Fixes: f4840ccfca25 ("zswap: memcg accounting") Signed-off-by: Nhat Pham Reviewed-by: Yosry Ahmed --- mm/zswap.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/mm/zswap.c b/mm/zswap.c index 59da2a415fbb..cff93643a6ab 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1174,9 +1174,14 @@ static int zswap_frontswap_store(unsigned type, pgof= f_t offset, goto reject; } =20 + /* + * 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_page(page); if (objcg && !obj_cgroup_may_zswap(objcg)) - goto shrink; + goto reject; =20 /* reclaim space if needed */ if (zswap_is_full()) { --=20 2.34.1