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 5EC1AC35274 for ; Mon, 18 Dec 2023 21:54:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E01A88D0005; Mon, 18 Dec 2023 16:54:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D8B298D0001; Mon, 18 Dec 2023 16:54:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C05448D0005; Mon, 18 Dec 2023 16:54:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A95518D0001 for ; Mon, 18 Dec 2023 16:54:52 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8078D1C128A for ; Mon, 18 Dec 2023 21:54:52 +0000 (UTC) X-FDA: 81581294424.24.F8A0992 Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) by imf22.hostedemail.com (Postfix) with ESMTP id 07C8FC000F for ; Mon, 18 Dec 2023 21:54:49 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wvfXSoWY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.172 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702936490; 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=nqsrGRSNXs2jP/UwD+ksz1Ps/gXN9w1X+zQo7BqyXLo=; b=754RyWRMhCV6ZV8mcHaej4ddMsDoOjZpHoLMY8KsD2GJ/mXIMp5DP2iLyzRTzEco8l0pLe DkcqhZKSqiRhdP3qeZzaMKa0AVa657tcx7caTRRI4tjkeR85HP7+cQlwlIyEuobDJX24dv prK84mansO5Rwqk7CE/KdYmrUMXaXhw= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wvfXSoWY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.172 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702936490; a=rsa-sha256; cv=none; b=tlzjtwvn5H8M1ilHNRGXJXVY6kPmqmBqYeFYcia8INoQ0ayQ6cQo2sPMgTt97zAuJUjhlb zWjBDFgCDwxJMmsLaJmMazBdd4ymtYalQOelNAd43eUAtvk/WkpU8zYfbIKgsHmwHQn76I HXErGye/wHkCkwTfZKj7nBvgRZLggUk= Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-4b6c517afdbso288430e0c.1 for ; Mon, 18 Dec 2023 13:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1702936489; x=1703541289; 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=nqsrGRSNXs2jP/UwD+ksz1Ps/gXN9w1X+zQo7BqyXLo=; b=wvfXSoWY4FqUQc3uyGNC/dPfcmJncXpBvJpAwM7T+TefmEL2Nc1OivCnk8L9xi/BbV aXlrMBlyY3IgOsQxRA+LtRE5DgDRr6RYCjg0sa3hmbHrOko/IrTv4CFFJb7z/h9jYofx coWvqTEcGxfTq06nh57iPkQ5tYu+TMmG7HmoIt00hEoeeBUVFarG+wbeNgUx9q4cL+bU C0p3JeCA6S3ZowLsO4qPwgsnRmwgBziK3rcGaiSsKX5znbFt3MVQ9VLfh2xWpnqro4+p r2e997KvLZpXg9G3rmzYdODZtf6If7Gc53/ThR5B+ZN3EQt/FWfX465VDe3VYOCkdhl0 z7oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702936489; x=1703541289; 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=nqsrGRSNXs2jP/UwD+ksz1Ps/gXN9w1X+zQo7BqyXLo=; b=QubyxGnyau/8plkgJ/RZ3mKdk+wG2QL9LzMN3bjm1w1YceXhUpBs+GMz+409PiN8CI KouQN3UemTvmWCT9goPFdL8hSISPRwozX+x0QUg7awe0m02fRqtUtk3uNpEFZQ6iMbmo 8XbCV9FR4TwUoq+yQsX4JnXlBCtlBrMP3IhclTGiIsNQM8Cc4k2PRWQoqvyi3tiuzPmK CCdAJK0b0jHmgOcNtkYuYvbTELa2e6fewEpp15tTLREd4YYnrsMcVlvjxW7ShBV9fR8G R2GlNuKZavM3BobBHauxYbqh2xHImFCXbihjiykx01DxlQDch3fevMyHBcc/k0VRbfZd rD4w== X-Gm-Message-State: AOJu0YwrmUgx0nGnK05TniTrYa6NkCe8TtgzHQ/FAwXQwneAWUy0HIlk a009M2Xw7iPM2YI8P8EyteAQDxBbFeNzpTeyaLVzYg== X-Google-Smtp-Source: AGHT+IHmq/AzLvS5Arc8RHX9mM7ruDwKw/HHft/+nkm5HdBMm8LoRUCVPEqhe0FFpHi9mzq7nBTThxUfZG+GJnD+NpU= X-Received: by 2002:a05:6122:3129:b0:4b2:c555:386 with SMTP id cg41-20020a056122312900b004b2c5550386mr12663985vkb.28.1702936488976; Mon, 18 Dec 2023 13:54:48 -0800 (PST) MIME-Version: 1.0 References: <20231207192406.3809579-1-nphamcs@gmail.com> <20231218144431.GB19167@cmpxchg.org> In-Reply-To: From: Yosry Ahmed Date: Mon, 18 Dec 2023 13:54:11 -0800 Message-ID: Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling To: Nhat Pham Cc: Johannes Weiner , akpm@linux-foundation.org, tj@kernel.org, lizefan.x@bytedance.com, cerasuolodomenico@gmail.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, mhocko@kernel.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, hughd@google.com, corbet@lwn.net, konrad.wilk@oracle.com, senozhatsky@chromium.org, rppt@kernel.org, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, david@ixit.cz, chrisl@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 07C8FC000F X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: mmk8kgx7ozkwprpi8zms131j1xq5rxc5 X-HE-Tag: 1702936489-945308 X-HE-Meta: U2FsdGVkX1+ZQ69TK9L+pHYhonSoBJudq8gyyp9UN2PplO2henr/F8HiemNybGhtiio7h9Nk/V9crspXnL7OUQZEtFr9HSxqwZgROUHHay4u/KpVCO23Ayu6zpEB2H/eZkiUl7SMmAPajURwvrGrp/jfE2eTanxfW+/lUtLwh3O6I4OVKA23XRh27eMZwzVN7ywLI7VjUjPHUIZytxJ6fSK1NOlkPZWu8AEj0JyjTulqp1a2Ae1cowjuWG5M2R8+fdTfBjy2Z+d8YLkjPVSR1u9paDUqfCE1rJWAGIbJtK1bzeFcUl09hFrztHg7aBNANumu45VVC6PrvBKlppZfot1D8eYVjLpu48FNQlHYUhZC2w1FiF8O7gQvTcAPzD3KueFfC7QVPkDSOfAzQiizPxdccCYjJ9T9TPOCIaeGwuGtF2iIGq0N+8gWuMo69eyg1ljva5jS0sq5dKs5OlY+TDDA0/3mMURx5Y54QViWcRQNs0pf7Zt2v/4mW5xuxOaFtIk48B9+bidWMXe/InQfk4RYkPuz6RrWYHkBoMzX/Bsg+92yYwoC0V5xacGjc8g7FM/5l3q2MIIRJoS1NTNK2o+IzwQltsnClVFPPhXic1EAtwiVQpiUDqRObOp6QfmEo2+cEd02yq3olAedsTZw3KlnTkALE7PV0NaKpZUmNDHV4ZhyPXK+sFkjlMriwZcx2V4i8Dds/L5vTEM2ljDzdwo4M0mvGCuntIpvFv643VuYI+PJ3TUfiDFTjVzrzvUJbMl11gCEVL0HEaiQX/xNWz+1iihm3na5uqfflHV/l4lWHS0q9BywLH0n6TXhQzaPDOeY45AItIE3vN1kcQZxiaAoVrxiVMHXzZ7ewabsuCiMvsaWmdQZ8w9TmAingIkquU334h+z6LnBFRrJ4DzDebBtkmEBWeWavHvGmnUOmucAG2hHFg6SmT9WFKTTd1n/voEIJ6BhqdNQQUGu+RW tDq0ksf6 Jdfq0FSC++CeN034E3+68RWFb0+pz+DEWu2uO8/Du1ONjZnkJxPwUYWQEKeRrWXqbFhWhBGyhgKQoBAx4Gpbwmhqo+qiQdwNjNGYiIBnCBfqA69NKgEE5Fi6SQE/MSVDIDLGoqz3FqS8QDFFN5c79fMzHi8Rverow+P009t+vQ+cz6WpyQXDFB454gdzuIcWW/Pgm7JBhzyxeKbkoGl6XHimmMe5xfTHf8J1U5cE0atXft0fKiocN5qi160mnbV5dd9d3fAZMsGU+JgClOrve8Wu3JRTh11ExEzOXpEz/BmZ9Y5gwSKf8M7xEZiLlxyFGwIFzO6HqFdJKJyUDHpTGHOxp/Jbpt/TJaZrem/yfWjOSCc64zIWgD+ezJrDcvrvkD5FIO1J6IUsdrV4= 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 Mon, Dec 18, 2023 at 11:21=E2=80=AFAM Nhat Pham wrot= e: > > On Mon, Dec 18, 2023 at 6:44=E2=80=AFAM Johannes Weiner wrote: > > > > On Fri, Dec 15, 2023 at 01:21:57PM -0800, Yosry Ahmed wrote: > > > On Thu, Dec 7, 2023 at 11:24=E2=80=AFAM Nhat Pham = wrote: > > > > > > > > During our experiment with zswap, we sometimes observe swap IOs due= to > > > > occasional zswap store failures and writebacks-to-swap. These swapp= ing > > > > IOs prevent many users who cannot tolerate swapping from adopting z= swap > > > > to save memory and improve performance where possible. > > > > > > > > This patch adds the option to disable this behavior entirely: do no= t > > > > writeback to backing swapping device when a zswap store attempt fai= l, > > > > and do not write pages in the zswap pool back to the backing swap > > > > device (both when the pool is full, and when the new zswap shrinker= is > > > > called). > > > > > > > > This new behavior can be opted-in/out on a per-cgroup basis via a n= ew > > > > cgroup file. By default, writebacks to swap device is enabled, whic= h is > > > > the previous behavior. Initially, writeback is enabled for the root > > > > cgroup, and a newly created cgroup will inherit the current setting= of > > > > its parent. > > > > > > > > Note that this is subtly different from setting memory.swap.max to = 0, as > > > > it still allows for pages to be stored in the zswap pool (which its= elf > > > > consumes swap space in its current form). > > > > > > > > This patch should be applied on top of the zswap shrinker series: > > > > > > > > https://lore.kernel.org/linux-mm/20231130194023.4102148-1-nphamcs@g= mail.com/ > > > > > > > > as it also disables the zswap shrinker, a major source of zswap > > > > writebacks. > > > > > > > > Suggested-by: Johannes Weiner > > > > Signed-off-by: Nhat Pham > > > > Reviewed-by: Yosry Ahmed > > > > > > Taking a step back from all the memory.swap.tiers vs. > > > memory.zswap.writeback discussions, I think there may be a more > > > fundamental problem here. If the zswap store failure is recurrent, > > > pages can keep going back to the LRUs and then sent back to zswap > > > eventually, only to be rejected again. For example, this can if zswap > > > is above the acceptance threshold, but could be even worse if it's th= e > > > allocator rejecting the page due to not compressing well enough. In > > > the latter case, the page can keep going back and forth between zswap > > > and LRUs indefinitely. > > > > > > You probably did not run into this as you're using zsmalloc, but it > > Which is why I recommend everyone to use zsmalloc, and change the > default allocator to it in Kconfig :) > Internally, we have a cap on the compression ratio, after which we reject pages because it doesn't make sense to store them (e.g. zsmalloc will store them in a full page anyway, or the compressed size + metadata isn't worth it). I think this is where we should head upstream as well, you proposed something in the right direction with storing uncompressed pages in zswap. IOW, I think such pages should be taken out of the LRUs one way or another.