Received: by 2002:a05:7412:8521:b0:e2:908c:2ebd with SMTP id t33csp63525rdf; Thu, 2 Nov 2023 13:56:08 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGU7G4OjzxRDFgsYarsEk+M84n/ikT52zVmyoQ3t8eKHxK36tinGA+pNmx/T60JkiBdx4fR X-Received: by 2002:a17:90b:1014:b0:280:c4be:3c85 with SMTP id gm20-20020a17090b101400b00280c4be3c85mr5671956pjb.23.1698958568311; Thu, 02 Nov 2023 13:56:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698958568; cv=none; d=google.com; s=arc-20160816; b=j6ryFd7Arizd+4pm5f9gJscL6+Fez8+15Xy8yfaDqApDa754Co8AVqyvq3R0rdmosj mWE5F1XcRyZ+88l6NhzvGhibqkZ8U9EwHo+zuLptItoAHHnA85VZhW1w7xSJ+hwwyg/x 3FvpCyldPr64b7KNCLfneTfrRBCynKzZTCTCCJbW3QGGVHLU/owZ2XJdaCywea/Gw/LL XgCg8jffMCjxMbENvwpYq/GkmJbdUg1c9l/U2BSErc+zrg2wALHErtiLlTPE4rtE61pV cQPWPDVsuoM5FeuSapiilwmmrtPefg+yvH5Xe0sJ8ieySceqK0NTHjbTIEa5KaQMEvG4 zgXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=c63Npi10wJWosRhm9gjhF9hBJGybG/sFGWhVUImu6vc=; fh=0S8/0X1lkSGYMgANpMnz8yz2hIlxkmPvGlpgGQ/VJRI=; b=fj62j8o5Gy303KTWYdxt+zFgg5gkPnaYZvvWBX0EshX7iOgmtIeRU7IsO7stnMNxK2 zGSsWunNjQ3GE5kfBLqtrh7erR75+ZOnjLjA3/VRxkwQYVSiieVsz9ZdGAMv9n1+xrG3 tPM3ruSvGpfyz6UTyUSuGZpV+LfLCKhdmBSlBm2wqEqKEn6PSeebdnsl4JO/3MlkzBJT S0AfQhhL1jRAOxwTGRD3xHHaQRz1Hqx1kx4oCOs/SXsuwKec/FNaWAT/AyK6z7N4baot MmGubQaNW2+IE18PHA3Y+YgkO71Ry0FijUERMU8ZPQ4VjDyYeCjJEQ7F2HNHfeQYI7Pn neiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=0zPgF+xy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id c10-20020a17090ab28a00b002748c1bbd79si427989pjr.6.2023.11.02.13.56.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Nov 2023 13:56:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=0zPgF+xy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 76F11807C873; Thu, 2 Nov 2023 13:55:09 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232831AbjKBUy5 (ORCPT + 99 others); Thu, 2 Nov 2023 16:54:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229459AbjKBUy4 (ORCPT ); Thu, 2 Nov 2023 16:54:56 -0400 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 62FA6195 for ; Thu, 2 Nov 2023 13:54:53 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-53e04b17132so2280875a12.0 for ; Thu, 02 Nov 2023 13:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698958492; x=1699563292; darn=vger.kernel.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=c63Npi10wJWosRhm9gjhF9hBJGybG/sFGWhVUImu6vc=; b=0zPgF+xyV7AAUoCzotxUr4INrjKwsIw0s3dJ90M7jizN6NQ9qLMlqkAC8vSrnIQSOm fvjumTs8+15sOMajx9qzDrIFroPxLvjWvUVWoG8vhm0NpJCQsoVkw+KVIHLWGwnsnh/4 anfFq7ZbC6xaWisAb2v+CO5TZPO989D4A1d22ePTcIHlcIc/8cf4PQbpcY+f2B669pnC CgI9ChlflwV71lpyUcxfQ3r3BASwUK7RMM8Q+jMFA8c4Q5kwe3sKRvpKD1rLMhLJKEk8 qvih+FjJqxB2jmoy/tjz66caNOcsQ//OlxAdn91M0eDrib4p6SfFnhI+b7WLloUgbOB3 qvFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698958492; x=1699563292; 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=c63Npi10wJWosRhm9gjhF9hBJGybG/sFGWhVUImu6vc=; b=sIcaaYFjuWfjOA7wch2C5a/uAoWcEY5dsCYpV3Cu8DgPLdTKOGZRLfl3ze9QULlBgI ivC8A8hJkSz+EabmhIVrN/n+KEd8CcaTut+5ng6uB6igPtPijZmFDl2XT9hHYw8u9l0J /LgFe0MLz/sHVLsmJaV4XA/91lvOshJnEIHxgDWpYjWvE58aweDfjDw8Ca/vWXs9amaN 8FT7w7kPp713YdQJqk3xqv8zka52xlHyhfexQasu2Om31t/ks//kZXO0dDmtEkNs9/TA bMK7ydmljtNneJsZuPX5WQZzSJA1FDPOUU9ewGD1tQnrSjLqFnAEZy2hNpIyMdRdLYmY 5OuQ== X-Gm-Message-State: AOJu0YyYqrCSdbpMlR9KtrsQHggraeedwgSsAmYewnaTxmNMnDZZYvsj WWkMKkrqneSjznf2P7p6QOxoy25jxdtS5xx6GwDIIQ== X-Received: by 2002:a17:906:7309:b0:9c8:f128:2fdb with SMTP id di9-20020a170906730900b009c8f1282fdbmr5328519ejc.13.1698958491500; Thu, 02 Nov 2023 13:54:51 -0700 (PDT) MIME-Version: 1.0 References: <20231102200202.920461-1-nphamcs@gmail.com> <20231102205022.GA3265934@cmpxchg.org> In-Reply-To: <20231102205022.GA3265934@cmpxchg.org> From: Yosry Ahmed Date: Thu, 2 Nov 2023 13:54:12 -0700 Message-ID: Subject: Re: [RFC PATCH v2] zswap: memcontrol: implement zswap writeback disabling To: Johannes Weiner Cc: Nhat Pham , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Thu, 02 Nov 2023 13:55:09 -0700 (PDT) On Thu, Nov 2, 2023 at 1:50=E2=80=AFPM Johannes Weiner = wrote: > > On Thu, Nov 02, 2023 at 01:27:24PM -0700, Yosry Ahmed wrote: > > On Thu, Nov 2, 2023 at 1:02=E2=80=AFPM Nhat Pham wr= ote: > > > @@ -201,6 +201,12 @@ int swap_writepage(struct page *page, struct wri= teback_control *wbc) > > > folio_end_writeback(folio); > > > return 0; > > > } > > > + > > > + if (!mem_cgroup_zswap_writeback_enabled(folio_memcg(folio))) = { > > > + folio_mark_dirty(folio); > > > + return AOP_WRITEPAGE_ACTIVATE; > > > + } > > > + > > > > I am not a fan of this, because it will disable using disk swap if > > "zswap_writeback" is disabled, even if zswap is disabled or the page > > was never in zswap. The term zswap_writeback makes no sense here tbh. > > > > I am still hoping someone else will suggest better semantics, because > > honestly I can't think of anything. Perhaps something like > > memory.swap.zswap_only or memory.swap.types which accepts a string > > (e.g. "zswap"/"all",..). > > I had suggested the writeback name. > > My thinking was this: from a user pov, the way zswap is presented and > described, is a fast writeback cache that sits on top of swap. It's > implemented as this lookaside thing right now, but that's never how it > was sold. And frankly, that's not how it's expected to work, either. > > From the docs: > > Zswap is a lightweight compressed cache for swap pages. > > Zswap evicts pages from compressed cache on an LRU basis to the > backing swap device when the compressed pool reaches its size limit. > > When zswap is enabled, IO to the swap device is expected to come from > zswap. Everything else would be a cache failure. There are a few cases > now where zswap rejects and bypasses to swap. It's not a stretch to > call them accelerated writeback or writethrough. But also, these > represent failures and LRU inversions, we're working on fixing them. > > So from a user POV it's reasonable to say if I have zswap enabled and > disable writeback, I don't expect swapfile IO. Makes sense (although now you had me thinking whether memory.zswap.writethrough is a better name). > > But yes, if zswap isn't enabled at all, this shouldn't prevent pages > from going to swap. Right, at least mem_cgroup_zswap_writeback_enabled() should always return true if zswap is disabled. One more unrelated thing, I think we should drop the cgroup_subsys_on_dfl() check there. I understand the interface is only exposed in v2, but I don't see any reason why it wouldn't work in v1. Let's not make it harder for anyone who tries to expose this in v1 (whether upstream or in an internal patch).