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 F10B1C3DA7F for ; Wed, 31 Jul 2024 18:35:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C2B06B0085; Wed, 31 Jul 2024 14:35:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 371B06B0088; Wed, 31 Jul 2024 14:35:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 238D16B0089; Wed, 31 Jul 2024 14:35:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 071FC6B0085 for ; Wed, 31 Jul 2024 14:35:17 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A5160160583 for ; Wed, 31 Jul 2024 18:35:16 +0000 (UTC) X-FDA: 82400900232.23.C188289 Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) by imf09.hostedemail.com (Postfix) with ESMTP id BBDA914001A for ; Wed, 31 Jul 2024 18:35:14 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RGAmls6+; spf=pass (imf09.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.51 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722450887; 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=FdDEDhBatiVQbzaYWZvpRwACycHKBzrY1H/vlaLquHE=; b=FWKGCLTmCfvnA8UdnMpsem83VdOLkigB/mXUIRGITTwsLD8YJn/9rClTKzwt/rWCuy0lJa mBvkTmd+VV90GCDmKNcUA06IVH85aKCSpuu17dhA97dc1N1URYVi2s+CxFyNUC59kd3wOo zEJLRMIO4bMBWwR3y1chqMHXUSkfMDU= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RGAmls6+; spf=pass (imf09.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.51 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722450887; a=rsa-sha256; cv=none; b=hIzgCaMmTe1vIAICsoAxwcr0njxpeuc+FGS0nFDNww5JHwdaSMflfUWXC2m+QnLLFJ1HwF FTlVQxtx6zLUacED3UKbpS1gB9J5kE/NXQsuhmtUcTB+Oq9yPDTjybDFpTgyTl3hbVFKn+ AAVVkG0evMu2Mqh1f0EEpWzgWjKoLOo= Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-6b7b28442f9so68565426d6.3 for ; Wed, 31 Jul 2024 11:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722450914; x=1723055714; 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=FdDEDhBatiVQbzaYWZvpRwACycHKBzrY1H/vlaLquHE=; b=RGAmls6+U2gcn0n+vFeHy1iGSUubnzAN4Vh5wOaq96lqoFjh1+U0byFSHASjOy3Avc MYmt6TwYqKjTAuBM22yJkusLXUgfPELV6jt97uIA3SZbnnPyUv6B5FeQQaTRiqSetdCJ D1gXOnk1lQ5XKiquj0R13aop4PIR+fHU8nMDb+LVinZmQGeTS5JvfZy9xOvPuLmJ1pQk YV+UZaZViDICMMR4DtcIAj0vv6To8M/7PbAjXiOSR9Ajcj/yb3eUzz7dhp0GAqf9BZj/ rS1WD7TRVVbInoqcZ8Pg1Vom07x0IZGewmf3k+HdQ1kKekgeQgFIQJbT3kyw0aRmScfw wR+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722450914; x=1723055714; 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=FdDEDhBatiVQbzaYWZvpRwACycHKBzrY1H/vlaLquHE=; b=opAhsHtUhz4klX897x/vG1v9g7D7F/tz857tLT3HZhw0DMMuwUjEp5xApzbU9JLN2D 4yS+pS3k4dqVmQXby3J9r8Lpiwe3tUIFZ9C5toovG8+3FLwIQIoXPVhPnUkb2WzEqg1h RQNmZHuemRA5Dsk9vi6f43HdI/m2cq8NBk45KWxfgGhuTiYxhjbnKddOikcO407szeC4 5mwcRQjuWDYHBCw47fwueHC8s/jZMu5qDqCoAw3IwLZFiY9j9dz+Euac02Ycitv2AO7Y 2T85h9sRfeN4Q0b418StBwpQfZ2EXvW9loUtbNs0weKfw2HQtFXOla9dx97aQhTqhNOO GIbw== X-Forwarded-Encrypted: i=1; AJvYcCVxoklwuFK/NRvjPqyqKHhO+dIgSDAdv53laoDz1Ho0aVeXbrqgVUYPAKxcTcw8QbvieUvN+WXTy+0raBWPpwpB4gc= X-Gm-Message-State: AOJu0YwzRpP2qM2IMV19RCab4C7ee7QGfCF/iL+4NopGyc4+RMuA5IJJ f7DyQ7LZrAksA5xJzySiZd4cTvtjltzheb3RLfuapHybyMSVJw3995c7lbFYjd26pfvip1n59Zd KYJaZfcHKjDsge++T5z/AJ6diIXk= X-Google-Smtp-Source: AGHT+IEuHFrKuYdYR9bW9QDOJ52WoNSCF9km2bgNw9D7wyjddAIiBhakhZRyh6QJApWCr8yi7bCaOjAczID+rNj7ymQ= X-Received: by 2002:a05:6214:3109:b0:6ae:ba6:2136 with SMTP id 6a1803df08f44-6bb8d79a1admr821976d6.36.1722450913709; Wed, 31 Jul 2024 11:35:13 -0700 (PDT) MIME-Version: 1.0 References: <20240726094618.401593-1-21cnbao@gmail.com> <20240726094618.401593-5-21cnbao@gmail.com> In-Reply-To: From: Nhat Pham Date: Wed, 31 Jul 2024 11:35:02 -0700 Message-ID: Subject: Re: [PATCH v5 4/4] mm: Introduce per-thpsize swapin control policy To: Barry Song <21cnbao@gmail.com> Cc: Christoph Hellwig , Matthew Wilcox , akpm@linux-foundation.org, linux-mm@kvack.org, ying.huang@intel.com, baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, hughd@google.com, kaleshsingh@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, mhocko@suse.com, minchan@kernel.org, ryan.roberts@arm.com, senozhatsky@chromium.org, shakeel.butt@linux.dev, shy828301@gmail.com, surenb@google.com, v-songbaohua@oppo.com, xiang@kernel.org, yosryahmed@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: BBDA914001A X-Stat-Signature: q3mkqszrdm9u1fx9y1n1cr8b5qq7ayqo X-HE-Tag: 1722450914-316522 X-HE-Meta: U2FsdGVkX18dS/1ZkMvn7eE+wThK1TLFIpHN2YBbMHZv8pRs1jk2tFAbiOmzlVPLYCGytEMM+duhp6e1VzlJClNqd42uvHW6IoU72vB2qwF/IPNs+C9tDNiuQ8p8PqhTIGL/OkOTpfsl5FUbrE12+4DhxJtF56NbiaPb6gCtv77DcRphQokZ0q1oaiOfFE/y1fQsZtIjRcGOlUy53NNgBjxNn3yxnumVJ8OdlLVKAYo0YCdMmO3r3fLPuIonvHSkZYahDG00D/CH29o4kTXF3XJbHKVenrWpPfDFtu/UDrXog+QGP/ozAlSYcAKFdCCTgh4hAGjaVUZevvW+BVrcEOdU7abVHD6rfMun2fy5mUoHJ6Z1a/C5xGoTa1iX24dIS26KmwnBJD6TF/RWyIlFurmz+XrV89W4Ht+1nC95u1Qhq5qFTe1PBnY1Wa6dS/mY8+WcX9a9PMGMVVNNngFJFCAretTKKtzaSwun8BQ4DhcgfVP5DK/Mqctlc8d5FU8PKPK2PFuL1MHaqHKn18NSya/oMHEdfmiNDu+xgt2sNxcRaH0Tz0wc63MVSsIZ9S98Ucp34t5deWolS480D3RJCqZDneGNg1z9G5QJJJg/+QL33D5iOnG7+PoevR4fbFD3QbYdhTXmMvSPE95b0V9b/Gd+2+BuDAxbvBRZ0wxZsRGBuezcG/H/4HGXmmRQ/6G5LU/Dsklb+h4xZMVGh1e/ip+kvIZl/c00QQ+Psl5u1CXPlF4tW3DdtAw33iga3XhqAWGDV1Y6iWaiDV8Neq9HhA/CBFkVYlzNUksH1ca9ACCxahLIh8ZvQbS2QTzF0ElQDePyiyovhlozzbtSrn/ck3sqIZxOnOqEkDXCuNsB5jcISvM/DUGSrZhHLgCS6aE3fzyG8zDps/TBdfOiOr+x/4UhACycoKgmApsArSMR7reoaoMkOV61r8GcK+Ypu0h6kbwpP7ODEAa2shIS6xJ 9h0zU1z1 q1iJSEf8MZbYDrTDBV/a+kzerX3V7Tyf/XwT4N6+V5cdHmiTf9EKMvIASscHTWFwPP3P312hPgpIsYBcbLiV1G8OoHbhMLK4lP/V8P0QuptqGOh9d6cDQbl96g283fE9zDE1eKe9GgKZjhqXn1u4xYvDREHJK8r7UXa2SAsZ3ljBdXSBnme4TapaioDEIlzUVPB9rNzNXQOIl/zY210/A4wM7Cn/7mZ/e5i2PFBFNV11OaucojKaB2pgzUGjqiOqHhTtiXze+4Le2Vvj+GEZIAEOWt9riK5f+fBnxwHbHkSnADTerZGE83Gp9mBVmLeI99ymy/XYnqOMpjaRI9pWCtEtR1Q== 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 Tue, Jul 30, 2024 at 2:06=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > > I'd be happy to collaborate/compare notes :) > > I appreciate that you have a good plan, and I welcome the improvements in= zswap. > However, we need to face reality. Having a good plan doesn't mean we shou= ld > wait for you to proceed. > > In my experience, I've never heard of anyone using zswap in an embedded > system, especially among the billions of Android devices.(Correct me if y= ou > know one.) How soon do you expect embedded systems and Android to adopt > zswap? In one year, two years, five years, or ten years? Have you asked i= f > Google plans to use zswap in Android? Well, no one uses zswap in an embedded environment precisely because of the aforementioned issues, which we are working to resolve :) > > Currently, zswap does not support large folios, which is why Yosry has > introduced > an API like zswap_never_enabled() to allow others to explore parallel > options like > mTHP swap. Meanwhile, If zswap encounters large folios, it will trigger a= SIGBUS > error. I believe you were involved in those discussions: > > mm: zswap: add zswap_never_enabled() > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3D2d4d2b1cfb85cc07f6 > mm: zswap: handle incorrect attempts to load large folios > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3Dc63f210d4891f5b1 > I am, and for the record I reviewed and/or ack-ed all of these patches, and provided my inputs on how to move forward with zswap's support for large folios. I do not want zswap to prevent the development of the rest of the swap ecosystem. > Should everyone around the world hold off on working on mTHP swap until > zswap has addressed the issue to support large folios? Not to mention whe= ther > people are ready and happy to switch to zswap. > I think you misunderstood my intention. For the record, I'm not trying to stop you from improving zram, and I'm not proposing that we kill zram right away. Well, at least not until zswap reaches feature parity with zram, which, as you point out, will take awhile. Both support for large folios and swap/zswap decoupling are on our agenda, and you're welcome to participate in the discussion - for what it's worth, your attempt with zram (+zstd) is the basis/proof-of-concept for our future efforts :) That said, I believe that there is a fundamental redundancy here, which we (zram and zswap developers) should resolve at some point by unifying the two memory compression systems. The sooner we can unify these two, the less effort we will have to spend on developing and maintaining two separate mechanisms for the same (or very similar) purpose. For instance, large folio support has to be done twice. Same goes with writeback/offloading to backend storage, etc. And I (admittedly with a bias), agree with Christoph that zswap is the way to go moving forwards. I will not address the rest - seems like there isn't something to disagree or discuss down there :)