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 9DD46C54E67 for ; Thu, 28 Mar 2024 08:16:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D66B6B0089; Thu, 28 Mar 2024 04:16:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 25F3E6B008A; Thu, 28 Mar 2024 04:16:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1007A6B008C; Thu, 28 Mar 2024 04:16:09 -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 E65766B0089 for ; Thu, 28 Mar 2024 04:16:08 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A04A21A103B for ; Thu, 28 Mar 2024 08:16:08 +0000 (UTC) X-FDA: 81945740016.21.73691E9 Received: from out-186.mta1.migadu.com (out-186.mta1.migadu.com [95.215.58.186]) by imf14.hostedemail.com (Postfix) with ESMTP id C061210000A for ; Thu, 28 Mar 2024 08:16:06 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=kOMXbJDC; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf14.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.186 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711613766; 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=5tn2JXPtKgDb/RvnAaA2HxiulPKE1lezZ4kqGlrru2k=; b=vszzQQ+SqHX7lRi9xdnkjnzxmYodfEo30qV4dLBJCRwfA323LBJNCMVVtBhSqO8SHJWPZv tfHljfT9zy5BHRUBr7zd5iu0HI0U+UGat4SYQJ3BUrLO1fx+VS6MU5j0P8gHbaDhdKo4Va 7KkWDMcqHlGm7cYUhTsthaRHF+Q84zM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=kOMXbJDC; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf14.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.186 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711613766; a=rsa-sha256; cv=none; b=BNMyyUhsRQ9HA/urMhRksPriWSpY+y/LI9lKjlIHcLRk0a9CtD8UnfrUmdkPVIDDwEFxIG JWSzp3nkNNasuWffOKUHf6MBwMZ8kzOBAZb3URYG6qdJcATuhPD7c9hF/SCFMrtWace/FB 9sMJgz4YFVY34kkBKXHXGB2LwsdwXdQ= Message-ID: <160b54f1-b578-40d5-a977-00b71fd22e34@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1711613765; h=from:from: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; bh=5tn2JXPtKgDb/RvnAaA2HxiulPKE1lezZ4kqGlrru2k=; b=kOMXbJDCyhekg4mdOuMJGuSHoVXwmrSC+tdEiXJm6Th2+sFjCM1dfRMYPcqQXINLd7J/2T xKLX06BUo0aabg+gmiTVW9sr7eMDj9ruk2h/27JDhTMlSusDB24NCxEsTSWmNtxx8adi0x 5n1miXWD9XczovsTmc8kX3cEoqQQ0Ds= Date: Thu, 28 Mar 2024 16:15:49 +0800 MIME-Version: 1.0 Subject: Re: [RFC PATCH 8/9] mm: zswap: do not check the global limit for zero-filled pages Content-Language: en-US To: Yosry Ahmed , Andrew Morton Cc: Johannes Weiner , Nhat Pham , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240325235018.2028408-1-yosryahmed@google.com> <20240325235018.2028408-9-yosryahmed@google.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: <20240325235018.2028408-9-yosryahmed@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: i1b8ap5dh3emswntwb8f6ngugz39hkrq X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C061210000A X-HE-Tag: 1711613766-709593 X-HE-Meta: U2FsdGVkX186mFibT2GJfSL6sWFUg3jj2HLMkVF2KgTi6Oswv7FzamDuDMkfcc4V5OWJtUq+IxmLmRRvsFLj/iuv2bFJ2aETbMiMMmZYMtXChu3Cj/HvV/Xa9Te5gpllfe0lPGUOM4/qLFqsX7xgO2uD1qBcISvi7IipfgDd1hZQKyoCM218imODlHQeXeGZ9m5QyPoiu/1eD3znEv5TcBEJKXzC2lvA0jszJoCp2YKCnZhn9HeNtuxbsd6qTkgPTFB4DD32+UkvATaUEuCwbkaJO2B1qDPKCpALVUfMIZ4jPiUAVL2UCEworjeGp6Z8Ai6YVyIZrAVKJupirLyR3eKEhW4ME3vd7juSj4J3QnlmUlkQAluR0CWNRS56IZLOoqVnhkwt6P/XlqIUFnW3F0gXyiA+nig6O4eWUzA44GmwRp4H+YbKoVzSmyL59fpma4Fp3zB988yPc5pozk2eVWAiOxrZNROJm+Z9yuwPrGQy1F7ibK01lLXU+MzHShI862VGrQ6JK8bwHyBmNiJWvzN2a85r1HZqugiKn0euGrolFPbD4sECO/QtpSWpqnQ8ZoEamhiTLwj2UxAn60v1y88mDu0E+Bo4LA8Xsm5v0obJ9agFRSHasNirjOG0s27SHwYpt5C2Q4JdmZSgdyMMVP1LIYJmgNZ8FF4Wrz1jlH29aWJuKWwmf89uVDAu1IpGNrsh3shGYJirY6JcZ49R2L7XR5OoJUnpbnBrlAurMc8L3uBgZgPv0dW3zv54bkDWa+KE4o10OtsP62vzFkXfyzCWR/nOgAemgegElnWbhmSIuWase4l1bTJIRBIRBe4dxCV0/TWEEdAshX5r2zuzJqG4ywjzSYh0IK4SZVjgPGyai6k2iHztbkc5D/c5j9aYAKSAnprnF1S1oZs3+clDODgLavfJVa75oGOkTMnRMFPqHqyxOi13kHpAoA9MswUl6K19qlAkCt+tFvZ345q ve8OwzhY KwpCoL0D6zrpm/zVdvUcIyKnN4UgvkAavZHcCzGHTDBPMT3/tyM4EUOtHhTG5A+J5YE7PpKWW/l9Lu0r0y6O6bGRbKSCGDRb1tJsbdfVPYVxn/bg= 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 2024/3/26 07:50, Yosry Ahmed wrote: > When storing zero-filled pages, there is no point of checking the global > zswap limit. These pages do not consume any memory that contributes > toward the limit. Move the limit checking after zero-filled pages are > handled. > > This avoids having zero-filled pages skip zswap and go to disk swap if > the limit is hit. It also avoids queueing the shrink worker, which may > end up being unnecessary if the zswap usage goes down on its own before > another store is attempted. > > Ignoring the memcg limits as well for zero-filled pages is more > controversial. Those limits are more a matter of per-workload policy. > Some workloads disable zswap completely by setting memory.zswap.max = 0, > and those workloads could start observing some zswap activity even after > disabling zswap. Although harmless, this could cause confusion to > userspace. Remain conservative and keep respecting those limits. > > Signed-off-by: Yosry Ahmed Yeah, it looks reasonable to keep the memcg limits check. Reviewed-by: Chengming Zhou Thanks. > --- > mm/zswap.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/mm/zswap.c b/mm/zswap.c > index efc323bab2f22..9357328d940af 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -1460,9 +1460,6 @@ bool zswap_store(struct folio *folio) > mem_cgroup_put(memcg); > } > > - if (!zswap_check_limit()) > - goto reject; > - > if (zswap_is_folio_zero_filled(folio)) { > if (zswap_store_zero_filled(tree, offset, objcg)) > goto reject; > @@ -1472,6 +1469,9 @@ bool zswap_store(struct folio *folio) > if (!zswap_non_zero_filled_pages_enabled) > goto reject; > > + if (!zswap_check_limit()) > + goto reject; > + > entry = zswap_entry_cache_alloc(GFP_KERNEL, folio_nid(folio)); > if (!entry) { > zswap_reject_kmemcache_fail++;