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 F23DAC4167B for ; Fri, 8 Dec 2023 23:56:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 39EF96B007D; Fri, 8 Dec 2023 18:56:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 322C76B0081; Fri, 8 Dec 2023 18:56:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C38B6B0083; Fri, 8 Dec 2023 18:56:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 079486B007D for ; Fri, 8 Dec 2023 18:56:17 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D0BEE1601F2 for ; Fri, 8 Dec 2023 23:56:16 +0000 (UTC) X-FDA: 81545312352.01.50C3365 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id D6FF114000B for ; Fri, 8 Dec 2023 23:56:13 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FN3C5EWM; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702079774; 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=peCMXDo9eaMOOydZ/8L8pLC6/eRpJHpJZfXn1ST7dfg=; b=ui2h59u/GAuSIlgn+dSDkYuoPtyDok98eNNBfd7qMZwBNG7t3uUQ/OLNeIa6Xw6JOoVo2X ML7W7Hs09meVaWlmHVaegpWPWiMZnsxf7v7XZ5BkYvKLaryaAcfr3UvF0RTpkae8GdCOUI /KT5ZBUlmnjieWANlYJ4fylan2Or93o= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FN3C5EWM; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702079774; a=rsa-sha256; cv=none; b=GbHHI3gbSg0OB2AvbYgEhaHefsyWFwfLk3lHrIk0iX6MQHKxss2iMrQaF/wGkm7LNpXNLL Oi9pSLfEvL5j4XkqUW36/i83iztH4sqlanrtcoV3PFAVCrXN1r1EIDrX4yz0nWgBZxcOSo dTZ8E0CmWE419FZ8Sw0pJ6D7SAmxgfc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CC41D6263B for ; Fri, 8 Dec 2023 23:56:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0C0EC433D9 for ; Fri, 8 Dec 2023 23:56:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702079771; bh=peCMXDo9eaMOOydZ/8L8pLC6/eRpJHpJZfXn1ST7dfg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FN3C5EWMkgZnPnVrUo9KwzCzdXZGuX8QQ31hzLsyt/D7rp0QYO9JOkmNb0MyMRGgI 1FnD+b1F/SXojZSeKBjSxIqcdfUJ8/EjdbNna2sUmIJQ/WtZ17TzZ7S9mwiotLPFcb zK36z82RHxJEstVWKEqgKr1aV8Y/MTYwTrPa3EKJSzXzdaqIVfC1HwpgmXI9h7GVTW B7+sCo4F2dMvC5TyF56UJ//8+Fs0ZZOqmxwwQeGusxqA8OPz9TDUFbMX/TfiihRSsp kSJy/KIqUdUNtEYaVAyJh/NLwrD8EEoehZ9uDZDdt1hK+aINS/q2rjKEgsRuZnhfmu /qDM+WwJrVh3A== Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-5bcfc508d14so2240664a12.3 for ; Fri, 08 Dec 2023 15:56:11 -0800 (PST) X-Gm-Message-State: AOJu0YzoyQEV1ejm5XaNHFeAAqpzo0FgkjpjqZuHujtsV2VQ4FOZ4xsg OcYswvWACMfCKqRyukw8ptARLOoljeukJv8CpIT9SA== X-Google-Smtp-Source: AGHT+IEdLUYuKILjBCDjMVvEgOABV9Uw5O0Cd4zdfhOQrwVlaEm7GUKQ5yvBboqDgaGFYG7tW1+n9bdx2pTjYygIYy8= X-Received: by 2002:a05:6a21:2715:b0:18f:97c:9789 with SMTP id rm21-20020a056a21271500b0018f097c9789mr846669pzb.113.1702079771090; Fri, 08 Dec 2023 15:56:11 -0800 (PST) MIME-Version: 1.0 References: <20231207192406.3809579-1-nphamcs@gmail.com> In-Reply-To: From: Chris Li Date: Fri, 8 Dec 2023 15:55:59 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling To: Nhat Pham Cc: akpm@linux-foundation.org, tj@kernel.org, lizefan.x@bytedance.com, hannes@cmpxchg.org, cerasuolodomenico@gmail.com, yosryahmed@google.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, Kairui Song , Minchan Kim , Zhongkun He Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: D6FF114000B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: jngduwsun3fr4ore1ra5hdjdjywsjwbn X-HE-Tag: 1702079773-374056 X-HE-Meta: U2FsdGVkX19Xm6BMnG0se6FZxFTrKw79+J1iKEtRSEfhSIQsHKlinI11DszH+n6scXRP8xaYoz3HjmFEGEywIbIOr6k8RFXqTwXWqyO3+3Q+DYtW4KVdd5ZSA4AR31lEc3edfKqAUwEScX0u4VV0wE7kvbDE9GBGTSAZDtddoIhjFhRjGbfH5Au0hR6X7snz87IbrAuiMK8VTNvUWj2yay9ATEgm/q3uBQqwyZesZvgbW468MYIGyBoBkAETlLblFVK5xenBNDrF2uWEI50DHWQkOH9WPp4Kd05N2xfpKz3t1/2ytKNKk2j9JK2oFQNAF2RbbHEy3H/ecMEs8NmZwT/9PTIm3GuzUAhD3MqBnXVkOFBAhiX9sOm2HI3snJ2Gj/cO6JUNF4ERsAZPhi0NqK3jtTzawYgE3iZo45H6BtXAKMCr5iHQOgaqGP3usyCyTogKMr9qduZp27SEK4klR4s2QRxHmBmmWhQefX4FIrBeIKNTvlXknRMilZaulYCNQ1LTQ+RiVay52euQIWiaGdr5jFDJV+vvt0gd0orApBfeZRazT2Jn9d1aRxXPaAOm1q7ksx1OTGnSYieHTOzbLZID2vTCIDbvQzlF4cqK4vQJdItp8OeeIPL3mzVkVonuJkqMTlhjT5xHXATYKtQUke4GbUnIdJnCxDjsR8KfKEyswfNnKm9RfgZ064XURNoWRwhzA+mND+QHdVGEaruL63ANAOcXCDRSL4+n37yQNwr3PS/VUuZlHpu/fDSDkea3Nm8tKWenbiyo2WzybgjZt9Ecpd8k7eb+ODf+yUeKPxDoMbX/ZKvBxXBsFraDcPN5ZQd/FjJQBRJebGXAetiDm56L/ROXY08hwP/ThTpoFM4/aJTpPfViGhys+vymGA16azBbHIJbkNj7sD8yzgAusPFr79bK/jpTY8r6yooBabQ1cIceiKnRED4Wj/l/hq+8d0qSfSHrTlsVtOJkD8Z O/NMzgjg QBPJr0oqr88GVYYcqHIY1lj/xbKgiFeJFCJcPKiuj05hAYOv1Cbfqq7SqrS5IUqBArM+oEIcbUVuTpvJ89LyOn5UACLKr+PnA2BKQMjLnWZC0Tw94AY9/TtRqWz9boBMVJWJbXjIDbEWUaJ2iF4wBP+l6wbi1HPra2VY2swfYNHVEDqeCOIuOBb8oRhd4rgzpf+MrDMJviaNAbcUTxAXjyCopSIzAatb3W0TABxedx9tK7K6VAUbMnPyU7OTK0ajLG/YwILGDkQ6+fxVgAI5Z+f0Lr6BZg8eEswrdszwCIiGnN9U= 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 Nhat, On Thu, Dec 7, 2023 at 5:03=E2=80=AFPM Nhat Pham wrote: > > On Thu, Dec 7, 2023 at 4:19=E2=80=AFPM Chris Li wrote= : > > > > Hi Nhat, > > > > > > On Thu, Dec 7, 2023 at 11:24=E2=80=AFAM Nhat Pham w= rote: > > > > > > During our experiment with zswap, we sometimes observe swap IOs due t= o > > > occasional zswap store failures and writebacks-to-swap. These swappin= g > > > IOs prevent many users who cannot tolerate swapping from adopting zsw= ap > > > to save memory and improve performance where possible. > > > > > > This patch adds the option to disable this behavior entirely: do not > > > writeback to backing swapping device when a zswap store attempt fail, > > > 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 i= s > > > called). > > > > > > This new behavior can be opted-in/out on a per-cgroup basis via a new > > > cgroup file. By default, writebacks to swap device is enabled, which = is > > > the previous behavior. Initially, writeback is enabled for the root > > > cgroup, and a newly created cgroup will inherit the current setting o= f > > > 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 itsel= f > > > 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@gma= il.com/ > > > > > > as it also disables the zswap shrinker, a major source of zswap > > > writebacks. > > > > I am wondering about the status of "memory.swap.tiers" proof of concept= patch? > > Are we still on board to have this two patch merge together somehow so > > we can have > > "memory.swap.tiers" =3D=3D "all" and "memory.swap.tiers" =3D=3D "zswap"= cover the > > memory.zswap.writeback =3D=3D 1 and memory.zswap.writeback =3D=3D 0 cas= e? > > > > Thanks > > > > Chris > > > > Hi Chris, > > I briefly summarized my recent discussion with Johannes here: > > https://lore.kernel.org/all/CAKEwX=3DNwGGRAtXoNPfq63YnNLBCF0ZDOdLVRsvzUmY= hK4jxzHA@mail.gmail.com/ Sorry I am traveling in a different time zone so not able to get to that email sooner. That email is only sent out less than one day before the V6 patch right? > > TL;DR is we acknowledge the potential usefulness of swap.tiers > interface, but the use case is not quite there yet, so it does not I disagree about no use case. No use case for Meta !=3D no usage case for the rest of the linux kernel community. That mindset really needs to shift to do Linux kernel development. Respect other's usage cases. It is not just Meta's Linux kernel. It is everybody's Linux kernel. I can give you three usage cases right now: 1) Google producting kernel uses SSD only swap, it is currently on pilot. This is not expressible by the memory.zswap.writeback. You can set the memory.zswap.max =3D 0 and memory.zswap.writeback =3D 1, then SSD backed swapfile. But the whole thing feels very clunky, especially what you really want is SSD only swap, you need to do all this zswap config dance. Google has an internal memory.swapfile feature implemented per cgroup swap file type by "zswap only", "real swap file only", "both", "none" (the exact keyword might be different). running in the production for almost 10 years. The need for more than zswap type of per cgroup control is really there. 2) As indicated by this discussion, Tencent has a usage case for SSD and hard disk swap as overflow. https://lore.kernel.org/linux-mm/20231119194740.94101-9-ryncsn@gmail.com/ +Kairui 3) Android has some fancy swap ideas led by those patches. https://lore.kernel.org/linux-mm/20230710221659.2473460-1-minchan@kernel.or= g/ It got shot down due to removal of frontswap. But the usage case and product requirement is there. +Minchan > make too much sense to build up that heavy machinery now. Does my minimal memory.swap.tiers patch to support "zswap" and "all" sound heavy machinery to you? It is the same implementation under the hood. I am only trying to avoid introducing something that will be foreseeable obsolete. > zswap.writeback is a more urgent need, and does not prevent swap.tiers > if we do decide to implement it. I respect that urgent need, that is why I Ack on the V5 path, under the understanding that this zswap.writeback is not carved into stones. When a better interface comes alone, that interface can be obsolete. Frankly speaking I would much prefer not introducing the cgroup API which will be obsolete soon. If you think zswap.writeback is not removable when another better alternative is available, please voice it now. If you squash my minimal memory.swap.tiers patch, it will also address your urgent need for merging the "zswap.writeback", no? Chris