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 DB19CCD11DD for ; Wed, 27 Mar 2024 02:21:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4E0F96B0085; Tue, 26 Mar 2024 22:21:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 491AD6B0087; Tue, 26 Mar 2024 22:21:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3595B6B0088; Tue, 26 Mar 2024 22:21:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 23C116B0085 for ; Tue, 26 Mar 2024 22:21:27 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F1A31A047F for ; Wed, 27 Mar 2024 02:21:26 +0000 (UTC) X-FDA: 81941217372.28.25867FB Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) by imf16.hostedemail.com (Postfix) with ESMTP id F2C9B180002 for ; Wed, 27 Mar 2024 02:21:24 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=vpehwpH0; spf=pass (imf16.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.170 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711506085; 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=r7kH22AwCzuZEuUkefxu0LWRPDiK+9VavfBLe/z9g4I=; b=J2KF5NAsJ8bdmgRkVHXh9TsRTiq3+U97g5Q5X6sVafYTUJMN54tPOOm95uAU9A715nmI7J +mcvz5bFGenek2QQVOW/IRjWUSiQaPFcAE0GJLJdPXLH3ztaH7TLIGxvOdCXSn5nlOxH3j JJlfwcjCyBoCvbbwEq772eA4u0C6qfo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711506085; a=rsa-sha256; cv=none; b=edVYCc6h1eE8Oy57oJUHTFRP/E8O9itBFktJSf2Ngejquf2rZ61crsJ15ivt9/CMNoJBtQ 9awwvu8+i8pV+Yqf1UYIWyiSRdbyzyrnj+xQ2nrCH+4kATNfj7yXonLQ0Mgw+eZP+Bffyu T8PEb+oJIV5vZJN7MHrpWBOWdu4FfKU= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=vpehwpH0; spf=pass (imf16.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.170 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Message-ID: <3e041120-cffb-42cd-8373-b254590f0e93@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1711506083; 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=r7kH22AwCzuZEuUkefxu0LWRPDiK+9VavfBLe/z9g4I=; b=vpehwpH0I+B9Vh7ynhlAvoaKoW0ELRndHaNhnJO6ezsgVlbZjiOXPomg9s5Lg+bdAF1lkD jWgTLTUVsXXqIRrXxyIBS4Zz9QyvrpjLIM/qpR3uBUrInSbuFqXi7tHjVCYUQyjBpkgd3O sTNregWkPZfKr9A4leNs7l5c9P8ysZ4= Date: Wed, 27 Mar 2024 10:21:08 +0800 MIME-Version: 1.0 Subject: Re: [RFC PATCH 1/9] mm: zswap: always shrink in zswap_store() if zswap_pool_reached_full 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-2-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-2-yosryahmed@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: F2C9B180002 X-Rspam-User: X-Stat-Signature: cbfu5dei73qiuopdmwabn5qjkxt9ynta X-Rspamd-Server: rspam03 X-HE-Tag: 1711506084-98668 X-HE-Meta: U2FsdGVkX1/mlg89cIKc80ApyvPFlAw+4ylCJZymPqN+uVrPLD85l9FapI86IN2/Qt3RNVn0ZLSXwzLaqYPU6qo2FvoTJdiNkfnPH4MzkENF77+cgvyhCY5NJaTnH37e2+Y0G1yIoHmvW25Pl/ocCj5g6aoMcvSRT2l+gXonuJZOY9hFgqPQiL1KqCfPInKPGu8meh36TKt0B6LyCHL55KZWmAaVYbv7N9r5JAUPKvJQoY26nPVQ0pr+481Rg/0iQV1q2pewN10YiLlu1lno4eMK2xvvw5Qi8Z9ZZFlzHegOb8nkCOh0FV3l4RgN0ib3jwTkNAm2dZfMgMaissH8kDVeHT8DmQBOePbe2b9ftolBMEo3yDqx1MeEcauoocKEg85ug6XIM7Nt0gP7P57wqaLYg83zmWpmFUiRbEf6i2KcjVK8S6Ah9m2MTthjGfvfWkKipFsN93TI/IGo/V+824WkQPmmSPpWJYVUE7i+2Sco3O7vzH6uD/gfH6wjb39OW1tatdsHND62aonAYHRGKj8XMCKkQJw3RQxwqPEC+QVdu6wPT0rL5AQj8nT308nVkO2T2qBJPPYECBHqeMpNZ0md2FAirWcTX9t4BojzwC0aZSceZZhRVlD9oqgJqxz0M1MzZLDzCZxn4ofXjxvqkB/jiPklH0qBLnKZs7ZuHTr2HeeSy9x2CJ2q66km/ChsCfBgeH4xZDPlpmyQgevPVb90WQZpZ0U3eof77PSUz/UZLHYnnhaXAJ8RRJL6SpbP2swPzMloaythhRru9r0wYYWGAk1cdq4Bq7ZC4R8IpvvPEc8yCDtv/AmDQ0JJNODnnTwujU/v+Cn23ExJTzWrW9hfiC+G0xwVvwVEemrgHsox1FsRrB1Nj0CEbg2cazfOaIOR/sQVl+/iYwd+LrWcXIW5fcjodkrVQNcN6R8cif7qNdndOxR2WShL0weuyG526eYnhtSFByomYzBOimq b/Ov/x4l enUo6t72bT3HNp4+Pb7P13/ri5NjhhVr/Id1wGzKzw9Hwm35rMLd9fcHkhrTw6tpllVtgdl2PaZl8uD4IEvk5/M8Arjasi3uZ2v0uSRJzUb/G5h6XsphsjiCpsTLnHAkzhlOQTxuuLpGT3w89ICS4qNEVuw== 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: > The cleanup code in zswap_store() is not pretty, particularly the > 'shrink' label at the bottom that ends up jumping between cleanup > labels. > > Instead of having a dedicated label to shrink the pool, just use > zswap_pool_reached_full directly to figure out if the pool needs > shrinking. zswap_pool_reached_full should be true if and only if the > pool needs shrinking. > > The only caveat is that the value of zswap_pool_reached_full may be > changed by concurrent zswap_store() calls between checking the limit and > testing zswap_pool_reached_full in the cleanup code. This is fine > because: > - If zswap_pool_reached_full was true during limit checking then became > false during the cleanup code, then someone else already took care of > shrinking the pool and there is no need to queue the worker. That > would be a good change. > - If zswap_pool_reached_full was false during limit checking then became > true during the cleanup code, then someone else hit the limit > meanwhile. In this case, both threads will try to queue the worker, > but it never gets queued more than once anyway. Also, calling > queue_work() multiple times when the limit is hit could already happen > today, so this isn't a significant change in any way. > > Signed-off-by: Yosry Ahmed Looks good to me. Reviewed-by: Chengming Zhou Thanks. > --- > mm/zswap.c | 10 ++++------ > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/mm/zswap.c b/mm/zswap.c > index c4979c76d58e3..1cf3ab4b22e64 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -1429,12 +1429,12 @@ bool zswap_store(struct folio *folio) > if (cur_pages >= max_pages) { > zswap_pool_limit_hit++; > zswap_pool_reached_full = true; > - goto shrink; > + goto reject; > } > > if (zswap_pool_reached_full) { > if (cur_pages > zswap_accept_thr_pages()) > - goto shrink; > + goto reject; > else > zswap_pool_reached_full = false; > } > @@ -1540,6 +1540,8 @@ bool zswap_store(struct folio *folio) > zswap_entry_cache_free(entry); > reject: > obj_cgroup_put(objcg); > + if (zswap_pool_reached_full) > + queue_work(shrink_wq, &zswap_shrink_work); > check_old: > /* > * If the zswap store fails or zswap is disabled, we must invalidate the > @@ -1550,10 +1552,6 @@ bool zswap_store(struct folio *folio) > if (entry) > zswap_entry_free(entry); > return false; > - > -shrink: > - queue_work(shrink_wq, &zswap_shrink_work); > - goto reject; > } > > bool zswap_load(struct folio *folio)