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 B8E54C072A2 for ; Sat, 18 Nov 2023 01:46:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C2FA66B01A8; Fri, 17 Nov 2023 20:46:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BDFBF6B01AB; Fri, 17 Nov 2023 20:46:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A80026B0510; Fri, 17 Nov 2023 20:46:11 -0500 (EST) 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 8F0606B01A8 for ; Fri, 17 Nov 2023 20:46:11 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6A64A12016C for ; Sat, 18 Nov 2023 01:46:11 +0000 (UTC) X-FDA: 81469384542.19.73B9F8D Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by imf10.hostedemail.com (Postfix) with ESMTP id F1D2AC000D for ; Sat, 18 Nov 2023 01:46:08 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=UW7OhMgy; spf=pass (imf10.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.50 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700271969; 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=8TcVT2LcZer1CThzsGm63Ib3f2fkvyB696jGdmBWhhs=; b=AJoIec8q7sI0w3oW3BWUjQiBPruns7ffq07S8WdKSc+pBmzZdE7BmSlscVLNjAGKDUWAaw 0tYy6y/CHVibieDiFCc5LWnULWhsLM8fw1aIi3sSqpidbK9UmIH0SGHVS06v5xB1jXOysX NTTNXbWi6MKmWRaAK/EUjn0eWm8u5+8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=UW7OhMgy; spf=pass (imf10.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.50 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700271969; a=rsa-sha256; cv=none; b=HEY44ZkkXfWr0ZCJIrmbQtaHoheaJabvmFVfB3oW/ChYKX2+lUeZgyhZstuEeTdpow1Z5h GKQ33ckWmokzfVgkI2qdQNmpw5PB2w18PFrA1kvhtRIdTprTmA3iVAevaawCut26ZUBUyO MES3nHSPW2/utoVeXJ4NrwctSngpXUQ= Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-50aa2abfcfcso1155981e87.3 for ; Fri, 17 Nov 2023 17:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1700271967; x=1700876767; 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=8TcVT2LcZer1CThzsGm63Ib3f2fkvyB696jGdmBWhhs=; b=UW7OhMgytpOYDzsPUKchXkvaFkUZFEFk2Gi1FIUg37gJntGgIDYhJodr6BVcD1AcbR VyICcVq2ZWfVvj9JghShsr0xpdkreW3eqYC2SPCTAqCaHK0r39d1PWmXbirhLNIVJwuS sLYTM45g/on+nC74q1P2/MP2qruzGcm5mVQIiLjtIKGgcnaLFsNCvWsq5vQUJh7MUqib 7vD6+gO+9LwqAST81ZNQ+it8FD4wfiKLJen+kcyshXo6UsiF4I1UmT1KPAv6WrOJZbG4 gPSyuKA42CUmZ48hQams1Rh1k+Plz5noz6Qb8upXC/FFQmE300rpdmE5VhbZML9y2Uh8 dM2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700271967; x=1700876767; 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=8TcVT2LcZer1CThzsGm63Ib3f2fkvyB696jGdmBWhhs=; b=szN7J/W9vTTl+Xjso1yPRbQJzSPLkBKj0udaghiJB+x4tWn0VIJDx2nAwC0FQtqmgz SyKDNcsfoctCcdanSpMVlQzR0qJdyM8bsMEl+A588speGnThtBldP3mt2KLZFAeZn8b2 WYpatGzYTOT/Ru4Kd49RGsue123GYEKXE4inyMIoDDdKgdtc13XM2v8JLkjC0Y6JThHG n08UtAwvntqGAos3cOt3j+i1alWVdKSxdmF1EcdRTorKQj+UOHC4m6r9DErNQoZ7COtl xEttgt1kvdAL2afSB3xazwSJNbGYOF3jtxPqIofJydYx4eRfhF4rma1IuZPWn3vbVxWo +hlw== X-Gm-Message-State: AOJu0YzJbUUKoVU73ChaU5z/jYjNnLgFYpb3t4UTfT/Cy7AJ5W6iHnvJ VdVc/lIlpsQaVcegzK9Qa0wJv1sOkKRfTi7v/gY7Sg== X-Google-Smtp-Source: AGHT+IFMnyE/Xetqtbvas5oGxx7sd1g0q/XEH0TVrahotyuGB1lIhpTcC0Pq5TUcWI34cmt+PyAbZBx5V5ZlTtOnmAI= X-Received: by 2002:ac2:4c53:0:b0:506:899d:1989 with SMTP id o19-20020ac24c53000000b00506899d1989mr1123882lfk.44.1700271966960; Fri, 17 Nov 2023 17:46:06 -0800 (PST) MIME-Version: 1.0 References: <20231113130601.3350915-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Zhongkun He Date: Sat, 18 Nov 2023 09:45:55 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm:zswap: fix zswap entry reclamation failure in two scenarios To: Chris Li Cc: Yosry Ahmed , Andrew Morton , Johannes Weiner , Nhat Pham , Seth Jennings , Dan Streetman , Vitaly Wool , linux-mm , LKML , Ying Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: F1D2AC000D X-Rspam-User: X-Stat-Signature: o7cnwimm631yrawe6pt3dk3ab6bxxcgu X-Rspamd-Server: rspam01 X-HE-Tag: 1700271968-819474 X-HE-Meta: U2FsdGVkX1/TcVMAuqUpuPZBOxHI7QSkVysIAUHpO1Bu8uWfug+LDnDkIpn8xXZYT5GV79Cf/lSYhfKOg42kgiafliJDLvaIHyTc0zqVzxG5q4kV0VLdX3szni1LgkEgh8KFlf4o7ivVygfnJ/wSplUjqzW101bMInT9eUAsHlXMhSlz46DhgGmQyQYETv1+gI37lnjJhmXH4PzZ4h83SgJ515Va9/TFrHrPszliNhvjYzw5hKTHTv71SxGwx21FPpqr91GCmGW9FIqAYJigVGZrhzw4nCQZeQE1klqGZimlMUNKKIvnu8an6xde36qtEFIzYqTT5jyl/Lx8BFNgo+f0UGpmsSsP1vipICI9XDzl/+QpNfIrUu4zin+WuOiEyY9tE8ggp058RsVQa+BL23XFAwIRpQ46w9dr/7d3snRaeFuYagqV3LExb5BVaNderU2SgOXDMHixOLMjM74ak9B+1fe7D2yIgxLHQlXsyEldN2k8aLufEyCXbNPh/Qx9svC5YBFMYWUbsPldSbxU7jPKX1aHzTG4zV/HyVKRb75PN4rTAPv4feHTrtLs2VCydrU4vt/hDjgRKeYP443DOjneZVboIGTK+Q/mJxF26OA72f45CFQg9zKC7aZKrGzZvFxgwTUw/3s5KSIS245/zS7SmxGJkeNtfvmorI1V9qJMts4CB4B3VF73ZyiwGFg0GZnsLAOBiuPjxSYjvSjVAhCZLjWFbnFYONu892TtWFAqH4AIsDltS8sf+3YTdbtWIciM0sSWFQhYx81eaDIe6gpapTnDE9C01Z3X5UjdqdqKlXcQviu4sJm7jHZylc2t729R2VhTwOOucE+4HtwvUmxnhsyQLjYfeldj49nexG+yxYcX1St70Vff6bgfFWyrWyq8g51Mw9M+mtmZMmgXa5ZiP5fwv/tov/cws/QS6O5c05Gd8ymsrqTO4uu7Xi7rQkGxyR5BrKZObt/+oxI emUM2kLW ZOBsoEmib4+fZhTOHYbO8lUN6foaQ438oycO4d8lq3GZMD3owoiJXlt6NNrKQdQdptRt03j6PaJVXRP2EARr5J7/YITfyGWNB5w3arA6+8UgCltpar6LOZD1+KbxqgX5j0xGtB6pERBuX28OuhB6qyejEjHjRw+c+JYIbv2dyNi4m4+EKkjBf93B3RekKvqXBRNzCzng/cWrD6BgnR2O9mebd+vuAgXPYnwnrD7vYD9VCi8CTVcgXop/A7AcEzHML/3sHD0eD4t5LQGNZgSDbds9y+rIRkovyU9DGTYFjujCta00= 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: Hi Chris, thanks for your time. > > On Fri, Nov 17, 2023 at 1:56=E2=80=AFAM Zhongkun He > wrote: > > Hi Chris, thanks for your feedback. I have the same concerns, > > maybe we should just move the zswap_invalidate() out of batches, > > as Yosry mentioned above. > > As I replied in the previous email, I just want to understand the > other side effects of the change better. > > To me, this patching is actually freeing the memory that does not > require actual page IO write from zswap. Which means the memory is > from some kind of cache. It would be interesting if we can not > complicate the write back path further. Instead, we can drop those > memories from the different cache if needed. I assume those caches are > doing something useful in the common case. If not, we should have a > patch to remove these caches instead. Not sure how big a mess it will > be to implement separate the write and drop caches. > > While you are here, I have some questions for you. > > Can you help me understand how much memory you can free from this > patch? For example, are we talking about a few pages or a few GB? > > Where does the freed memory come from? > If the memory comes from zswap entry struct. Due to the slab allocator > fragmentation. It would take a lot of zswap entries to have meaningful > memory reclaimed from the slab allocator. > > If the memory comes from the swap cached pages, that would be much > more meaningful. But that is not what this patch is doing, right? > > Chris It's my bad for putting two cases together. The memory released in both cases comes from zswap entry struct and zswap compressed page. The original intention of this patch is to solve the problem that shrink_work() fails to reclaim memory in two situations. For case (1), the zswap_writeback_entry() will failed for the __read_swap_cache_async return NULL because the swap has been freed but cached in swap_slots_cache, so the memory come from the zswap entry struct and compressed page. Count =3D SWAP_BATCH * ncpu. Solution: move the zswap_invalidate() out of batches, free it once the swap count equal to 0. For case (2), the zswap_writeback_entry() will failed for !page_was_alloca= ted because zswap_load will have two copies of the same page in memory (compressed and uncompressed) after faulting in a page from zswap when zswap_exclusive_loads disabled. The amount of memory is greater but depends on the usage. Why do we need to release them? Consider this scenario,there is a lot of data cached in memory and zswap, hit the limit=EF=BC=8Cand shrink_worker will fail. The new coming data will= be written directly to swap due to zswap_store failure. Should we free the last one to store the latest one in zswap. According to the previous discussion, the writeback is inevitable. So I want to make zswap_exclusive_loads_enabled the default behavior or make it the only way to do zswap loads. It only makes sense when the page is read and no longer dirty. If the page is read frequently, it should stay in cache rather than zswap. The benefit of doing this is very small, i.e. two copies of the same page in memory. Thanks again.