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 4E902C4167B for ; Fri, 8 Dec 2023 01:03:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 95A836B008A; Thu, 7 Dec 2023 20:03:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 90A616B008C; Thu, 7 Dec 2023 20:03:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7ABAF6B0092; Thu, 7 Dec 2023 20:03:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 64D936B008A for ; Thu, 7 Dec 2023 20:03:45 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 40D6E1A034A for ; Fri, 8 Dec 2023 01:03:45 +0000 (UTC) X-FDA: 81541853610.29.79754A7 Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) by imf22.hostedemail.com (Postfix) with ESMTP id 8BB6EC0014 for ; Fri, 8 Dec 2023 01:03:43 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L5Vx1SCZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.42 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701997423; 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=FFmGbo8fhXTr6Pczms9GfEwRxaNflz7F0LyZ8zkEvYE=; b=KrGVHPn5p5AzUBkIVMw8CdXDxxdlDnhx3s4faaxxG16hyxxmRTKjuQCnmKCouSLW4GFyxW cUt3wvUMdPKLxCQohYaA35XykOLsvEgH6j51tlBXi/JBahOktuhcike5MSRjfMOXqwUS/b ln85eNYJbvXBxa4LWTkiPY/50CHgKk0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L5Vx1SCZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.42 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701997423; a=rsa-sha256; cv=none; b=0k7/JYUknvPuRXwanSAqtCrt9xD9WEeffMu9ZTGAha9WgV7QQpJsdEjorXfHfXfyuy7R03 vPU7CGRoeHw0uV2DkzFUegwsHfKIk0SWGkb/rcD/WK0s+imeCuGyb7/rXL0QDhuMe9lLTr FcZMwm1lRiRt9UeGismkcnHuwr58hEA= Received: by mail-io1-f42.google.com with SMTP id ca18e2360f4ac-7b373d61694so60663639f.2 for ; Thu, 07 Dec 2023 17:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701997423; x=1702602223; 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=FFmGbo8fhXTr6Pczms9GfEwRxaNflz7F0LyZ8zkEvYE=; b=L5Vx1SCZD/XDQwcPI/T79btalQnBXPpcQYOCWLIZiax7RCFEYrmLHOCcJUqPuPL2AC h7PUZvYq1vW2s7ZjExU59KolQkTe2sM8+yjcQr6GF8GlwA+p5xtLBySY0vYUAAjgpkib isq1lYKrFJywSgO623FBdyTiLJ/osB8eF3fEc3fON6iiFHNYjatLtDvdMqRpRGBl2EWD VoqCFKuxH2K6C7jX7GHsDLTt9bLTAVUxUdrwq5dCZiEhMLndSiMAp3OvayRXyJZ3GvgW LfNMmdM4zM/1jMa8m0YIV0z7t+jI9DmtnyGfLd9x6JflQUNdZTI8qW3lc9qPZmpCUk6n qqPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701997423; x=1702602223; 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=FFmGbo8fhXTr6Pczms9GfEwRxaNflz7F0LyZ8zkEvYE=; b=PM2W++lWJTXWt9FRJrUy+eW0LySag3nCfX6cfGzBKnlcDcUucgdlKOGO4uMBlkuYyz 2tyLjNQE8KkPL84dFf3RR5TUVqBcNl4czlCrXawqRlUPkWYguvfDCMPICrj+Ek1gF8vF fL08bmcCJp8u6dRgKXTMdLkiP7ERG/AX+Lw4Uq88HKpYoNenwKeG/AyyZocHPLa3kU0t anLAAofuroqfeXgs81myJ7sX3kIcfGt2t/Bmq3+BF8ZMig29Naf64iX0cBF8J2JmK/hv nBBbtr5wMgLnDF4X+rRX3897N3PDznwDSkm8wCCAFLDAXx+lq/g88+xi0g9JI3ZSoqUh BCRg== X-Gm-Message-State: AOJu0Yw7oEN0fGx2sqnr2cDOqsptVrQu7mP7qtkfmPeLc7QSXVFGRyVV RIOS/Knv932kU0z3L/s2NaM5rqrdRVY1Um8mv/A= X-Google-Smtp-Source: AGHT+IFwX1Howrjsss3Fc41+vp34/Dggj/8S1JvGY4jfBi0ZC9zOlRS/1JlBCsDJQwhae0D1y2gEjkvL2as9w954e24= X-Received: by 2002:a6b:cf16:0:b0:7b4:28e4:8509 with SMTP id o22-20020a6bcf16000000b007b428e48509mr3612735ioa.11.1701997422578; Thu, 07 Dec 2023 17:03:42 -0800 (PST) MIME-Version: 1.0 References: <20231207192406.3809579-1-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Thu, 7 Dec 2023 17:03:31 -0800 Message-ID: Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling To: Chris Li 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 8BB6EC0014 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 34jtecpsojdimgzc9k7foqa1yj94bezo X-HE-Tag: 1701997423-255193 X-HE-Meta: U2FsdGVkX1/pqt+erIJYyeI/6nHM9jac5tEAqZh1Q771wM5DsdsLzxHtu3O09GjqXYumVFlDdYuJqeJ7/RP08k8ZJj9IwW1H/U7iB1anF/brK+hS5nQbdvR7PrLEFg+BC/Wg5g1CFkTuU9Wt/8rNkCR+dgJ2X74FcJxXQrNVxQfW9YrhP6/yWhcHfG/79WLXf7e/g0U6P7czAz8d4xvkXGq1cOjQ4+9MfvghIBvZQ+AnyXBA4yPshVdBGRYFdcpkdzI9YYGaJH+4nhEpko7zaoqg4fcDCstVaaFtLmO6oG9bEEDOklH4/961BCruu8mYJIjRBQTQEI6sVWl5gIH3XUuDgX8zkVHavXVtafaq1VSSneQb+Vs4EuGyYoCXNBiOV+Q77f7yvbCfFs/zj/okMp3o/WYUhojUjOOBTGoxrxdzlautdEzj6gY1Cnf8t2fj+5OIgM1IcYAj9i46IfgokByesz9guZLMZHj110DxmhnVxSxqR5zUOvRk+hUMxSzDOLYAQ9PGyCM2vVrfvEjB3ZpoF6o+uOEGX4bmfdCOOS8ALJzkWn++zEedzR4QF5YABpRcFqJO5CT0sorZDXoHchR54sNxzijYKIRhe7+4zcBAvNXIIZst2K888PecvRKG5lHm8mo7Jl7TS57y2nbE9VHMLkV4xFHf7cS6uQFAa0R4JXbXH2ophgJtdRbcXe8aH3eGGjIwM/90kAlRyytDO9hE1x5f9JsPUfM0lVS+lNtYbQc93jwf//5wzpBe78ghmCYcAfKc73DkU0RZoJjvNtq3QTJHOTj1hl9b1HSER1Lt9haz4ur6h0uHsf4mW/+JklNC1WtmXDopLVv4rcs9krP5rHRUl1y3RNe5Kv9xnrzTBOXNBMaoSskwhz7ZnGbVhiQPnPeeQTEbSCkYZHUKGTZDYKgypSGoPzWrJLAUn9/T5kKj8sVQO7rdgVm5DsSu08JNMScB1A+hFZvet70 K/Ag1S2y WfLLviRMwmRIuWiTjOQzORxTGAxw04MCC7yMTisJrJqhlC4ccxEJBdVybWby3V7suCt+lgOObmGTi4IQH8A9FBaIhV6SDXGEfKDVv3APkGfoUbhLYgptEU1yMYjK7/HSvD78o/yICqIN6vB15gdZEk4KRJJPLEHk9LIQL3pUXvncU+tRx2TRkKoJFlpFUwsWfhxZWFYaKE2trGTJ8Y2Za4keQ4DI7Y69xIS+P9z0Ome/GLqJ4/qYTexGUVHCyyxvbmuNyjrC2eMKoKVVA8Ed9c52ksSPt2sqyAIeFu8+XljADU5UIo5gvw4R+PQAbUJJrJLeUyOKAS2SyrW1Jdnab9/0P+MdA5RqGZ52B6zaUDVCpQ/uV7UBIXJp75Tb/00aUixcVTFq0lChg18w= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000019, 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 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 wro= te: > > > > During our experiment with zswap, we sometimes observe swap IOs due to > > occasional zswap store failures and writebacks-to-swap. These swapping > > IOs prevent many users who cannot tolerate swapping from adopting zswap > > 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 is > > 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 of > > its parent. > > > > Note that this is subtly different from setting memory.swap.max to 0, a= s > > it still allows for pages to be stored in the zswap pool (which itself > > 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@gmail= .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 p= atch? > 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" c= over the > memory.zswap.writeback =3D=3D 1 and memory.zswap.writeback =3D=3D 0 case? > > Thanks > > Chris > Hi Chris, I briefly summarized my recent discussion with Johannes here: https://lore.kernel.org/all/CAKEwX=3DNwGGRAtXoNPfq63YnNLBCF0ZDOdLVRsvzUmYhK= 4jxzHA@mail.gmail.com/ 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 make too much sense to build up that heavy machinery now. zswap.writeback is a more urgent need, and does not prevent swap.tiers if we do decide to implement it.