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 0EB27C3DA7F for ; Tue, 30 Jul 2024 21:06:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 96BDB6B007B; Tue, 30 Jul 2024 17:06:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 91B366B0089; Tue, 30 Jul 2024 17:06:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8099A6B0092; Tue, 30 Jul 2024 17:06:32 -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 63D5C6B007B for ; Tue, 30 Jul 2024 17:06:32 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0AE04C04EF for ; Tue, 30 Jul 2024 21:06:32 +0000 (UTC) X-FDA: 82397652624.23.90B642F Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) by imf01.hostedemail.com (Postfix) with ESMTP id 410F04001A for ; Tue, 30 Jul 2024 21:06:30 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eL1UluX9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.169 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722373586; a=rsa-sha256; cv=none; b=NZ6jNlXlXrz+w+HsfICQ/cDqwBqaJGgWxZUaQbD5HZW37xewYNgjg+9H46ohPAptH1dB91 zLpwYogrgOBgVBMJ0d9Qlbmgn4EASW4Re/jbHTR3neVu7Zztl2uWO1OldUJ5JBBsWFipqT xzOsogGjxItzNQVU/mFNWdaGd/0VE04= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eL1UluX9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.169 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722373586; 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=WG3Gt1G23WdjFYsF5tUz4H0BzIw3odLjVlIK2ek5M8k=; b=lRUmWNQxTdKQ9/wkFnA6tg/c4XgF3BzcY40IKMcWttOn+5hbUuHEJ2kZTJU7dUcPp9s4o5 n7Bfn4kTfH0A8cd1A8oyLd4S2Frp4Kb70r/pntxmDbngVpa4nKiFu317hbFhp1yJN/TMcY KwWadkwXjpyzY7BKo2D4ja/UqrNtUpI= Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-4f52bd5b555so179054e0c.1 for ; Tue, 30 Jul 2024 14:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722373589; x=1722978389; 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=WG3Gt1G23WdjFYsF5tUz4H0BzIw3odLjVlIK2ek5M8k=; b=eL1UluX92UnXmKhqIHjyO1QjR4ed/fL9xdXruesGcWjsVKVp02qwgVXndXRjToJvaY yJIAtKy5ZuPsEnL0DjTYQSvmb50dQo3g5NHeYzSpkJaip+/5fS9LpqyNxTBJbSXMzO0x fdXSX988SX4GAMPrh4NdRNqMorf8ok/eY132w5jXUPqpQ/j1KxjZJ+T9/bvYx+6cAFeT 23z/UKCELs745S+fr3RGXJ9dfT94SlFIJODiyJeXmv3R2YnG3rSUl96A6BU78GtvCTyH Y7hYz4YHXSU1PJ4WammANe7OPr8RTHmEqBiAaAfpLL+UZdLyxa9bIpp2Dt25a2A59N/a kQTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722373589; x=1722978389; 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=WG3Gt1G23WdjFYsF5tUz4H0BzIw3odLjVlIK2ek5M8k=; b=lJpd+lXBVKnpZIcVodcnTKzzNbA4pnydHwEpYeRPxP2YdpX7+0FErgR2DDkYrfsUzk FnIssoD6egxmLBUze41kAXHavQEecQV4Q5a6oHI0gc5c93wRDriIhGyNbw4wNx+S5At6 WfTSCoEKB3e8f+wEfkqKZ2tnpotb0QgRaRenQ9+U2OsXbRPN4Cf5mlhQAyZ9YcYBQ7H7 qsOUBf/c7vdLonICHlqdCrr2b2i8C/H/FhhdKIutotsPA76cX/6OpX31sAuOkpnz148z Jvpg2YPjj30vMLiqEbod2suPoXulGifyy2PvgZZ1D0iF+KAsRGn2XWY7xN54906jOoXU 1coA== X-Forwarded-Encrypted: i=1; AJvYcCVP8nY/fC3NZWDDys3oNJOXKfWNQg7HeVtbrxCe+2/e9IebaSM7XW3EPbn0Xttzw/DvALNw21WXjY5v/F3bXdRUTE8= X-Gm-Message-State: AOJu0YwIbQpaFT7Q7ZtsNdKfxG1xpXtnDYR5m3TA2vxkYWrcp97tQVYk BwL+WDwHWfTbwgNptcJW1uLAhj5BpkgxZ87fKCqvfOLJNvWNHSRe8XeVEQ2MeSw+p9W8JZ5e6Sb 3OlU7wqXctq4NN+MCOAjcV+6wgOE= X-Google-Smtp-Source: AGHT+IHP8BxyNMgmlFObFcaCBGgz+PTn1MIlsm0UPlqiJ5IRjvYvHp0Uv1eb88Z4ccrdAoAabbZWtbeGNCDU97bG07U= X-Received: by 2002:ac5:cd50:0:b0:4eb:ddd:4b95 with SMTP id 71dfb90a1353d-4f87f6c753bmr2031976e0c.0.1722373589200; Tue, 30 Jul 2024 14:06:29 -0700 (PDT) MIME-Version: 1.0 References: <20240726094618.401593-1-21cnbao@gmail.com> <20240726094618.401593-5-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Wed, 31 Jul 2024 09:06:17 +1200 Message-ID: Subject: Re: [PATCH v5 4/4] mm: Introduce per-thpsize swapin control policy To: Nhat Pham 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-Rspam-User: X-Rspamd-Queue-Id: 410F04001A X-Rspamd-Server: rspam01 X-Stat-Signature: ihx1obj496tcd44h4mgpfjptek3gds73 X-HE-Tag: 1722373590-988474 X-HE-Meta: U2FsdGVkX18uxW6vouwEy+o6F9ZWs2Co2n5IWE+YDyqIgT5GHrkmXOZumUhSVsLAPO23hSXtnNuw3DXLU9OYp0WttXqcClHVYSNi7125bpbNNVhMnjWagseFoRlGXEurkOMg+h6kOpPW3C8WHENydDcwFN4410BIURPFAVIEuSWyAqHK8i3DG8+cCkpFndDETgyVov38VZoQ40gubjKzrl1JuFJrsE3bZbO26B/OHLKG0pDr/1pI4A34TZsTLAX33qgDahEcC3qnLHQ0/IYvrLxbirouJrxB60EAV24hpazuOraY0mwjxWxpxwoBV7O7m1U+7ijBGHyDXC8lufKCpFIrMJ/SCdfOr7cml2bgEu/rMxExtHpZHi/Z59ocObcug42TBV3BGiZUhVeglveCEvxBBkIOaTi6Zl1wjU1aqSKeT3kvhJI/htHukxRMwiG58iFwIUFyyS0MIqwrENWm+opjrSzAXM+8YlyTNzewydvU4E6XBSl4hjDDUCcnHLpocTTR+39+HRUTKNwvNJ/ZqE/39Cf39zISYXFUuqLyW053XNegM/+gTdYOecLQ2BnGoN4l0ShuEurtsAw96LAKPnUKLL7E0TkdHSqNBS7c+LqZl01yqYphk0MhZu9HXwpXMeDnBWw6zz3VeYw1Wb2qiBa8q8MwiLLSUYtqG1ydQNpQ6lkhZVhVnAgNto0qYHr5H2mRWr32rfFM1BeyHW059l+ai8mmxP/MnFKO0SXQAo5Fw0xv2gFUMEj/9pITETZJ1o7hs6sfjeKOpLujAZBUkegeOF86y891dBhfLH3fSmTpNmAvOWyEr+s0FnCEhaAyvc++i1k4B2ECehByCctJB+Kd71zZpP96wTfxd8Dz/9aqM4ypNMFOXeXz2kxamwOLN6GMe01+9icWct6isdq831CfwGx8ToUTKwFHzM+JSMxFL5oQFo+yiX3B/5YIHah69OG6pt446ro7L/UhRrS LWPy/B20 1B+BbFjphfYb3gDRp1i0v3Hc0Kk4SdZ2CsQ89eW9oV3vHI41oVADG/UjPncYjBIEQVN1b1AkdoqabC+08z8+pb7up/Q1hp2T2TTVclQDpOe6h2uX1DzIu7n00GUAKJMeLikJJvZmIeLi6ESI9B9Btb6/8yfN8vCQMLgsbK68OY71d+y6qn4U9Ilhpv1R0jb1XCtUEBJ8sZsyNzOxiuITrxc8PSmlGW047otEWSbjKvAqRyGKrUyybZ6j5WK9Lj36OcjfUIx+3IozIjsjnEp5qN3cs+UPNC6pP/VYaf1O1VItRy1/eHC5FPDJawsPuzAAxVCRusW15VUKuhGrphzC+sGJvFSrfHzKuycc7Qa4UAAFHumzrF0lW8dhv/XVUZPVtpMSIoqvHEIqQk89s/Lk4FTN49KEgP2od1aH+z8uracO4kKiEMIcq5+2MpzPfRxRnbzBr 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 Wed, Jul 31, 2024 at 7:28=E2=80=AFAM Nhat Pham wrote= : > > On Tue, Jul 30, 2024 at 9:30=E2=80=AFAM Christoph Hellwig wrote: > > > > > > Well, that is the point. zram is a horrible hack that abuses a block > > device to implement a feature missing the VM layer. Right now people > > have a reason for it because zswap requires a "real" backing device > > and that's fine for them and for now. But instead of building VM > > I completely agree with this assessment. > > > infrastructure around these kinds of hacks we need to fix the VM > > infrastructure. Chris Li has been talking about and working towards > > a proper swap abstraction and that needs to happen. > > I'm also working towards something along this line. My design would > add a "virtual" swap ID that will be stored in the page table, and can > refer to either a real, storage-backed swap entry, or a zswap entry. > zswap can then exist without any backing swap device. > > There are several additional benefits of this approach: > > 1. We can optimize swapoff as well - the page table can still refer to > the swap ID, but the ID now points to a physical page frame. swapoff > code just needs to sever the link from the swap ID to the physical > swap entry (which either just requires a swap ID mapping walk, or even > faster if we have a reverse mapping mechanism), and update the link to > the page frame instead. > > 2. We can take this opportunity to clean up the swap count code. > > I'd be happy to collaborate/compare notes :) I appreciate that you have a good plan, and I welcome the improvements in z= swap. However, we need to face reality. Having a good plan doesn't mean we should 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 you 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 if Google plans to use zswap in Android? 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 S= IGBUS 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 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 wheth= er people are ready and happy to switch to zswap. I don't see any reason why we should wait and not start implementing someth= ing that could benefit billions of devices worldwide. Parallel exploration lead= s to human progress in different fields. That's why I believe Yosry's patch, whi= ch allows others to move forward, is a more considerate approach. Thanks Barry