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 BBAEFCD4857 for ; Wed, 4 Sep 2024 17:41:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 560086B0316; Wed, 4 Sep 2024 13:41:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E9AB6B0318; Wed, 4 Sep 2024 13:41:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 363F16B031B; Wed, 4 Sep 2024 13:41:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 128BF6B0316 for ; Wed, 4 Sep 2024 13:41:20 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A325F8012E for ; Wed, 4 Sep 2024 17:41:19 +0000 (UTC) X-FDA: 82527772278.05.50CEDFC Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf08.hostedemail.com (Postfix) with ESMTP id ABA57160003 for ; Wed, 4 Sep 2024 17:41:17 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=hMNytTxG; spf=pass (imf08.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725471550; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UZBuD8ujlpQgbSRbizirR+La9i0Qd++C4v9xqo3Ygjg=; b=wjAu75My7hfbxvBH0xqMr2chxqk7mqdCbr3JoM+iayb3RHomz4DQdbsJTdHkPWp/1hSe3L TfJajTnJZ+m/cqql7PlzmWFMu0UqqFweJsiCxkndgmBonefyjsAAWmbquAalPFdNDW87UZ 9ETkhgb7H7VN0HdGNDah5qcCkzEIrxo= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=hMNytTxG; spf=pass (imf08.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725471550; a=rsa-sha256; cv=none; b=zOBrkOStH8KiBGM/38+CYR8qD/nJyGQDdQ7tsSUR5h0i50FZMeyrjOi/UGxB+WDuXQJhWh W9XeseFJSaPMaaNntz8LTjZje3NWzWK8yjSjyEp47QS7rrQhJGDqvlIvLlmPgw2xNbtFJa RoAygNvUjEHEsbGmsULftmr+753T9+U= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2f029e9c9cfso86646891fa.2 for ; Wed, 04 Sep 2024 10:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725471676; x=1726076476; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UZBuD8ujlpQgbSRbizirR+La9i0Qd++C4v9xqo3Ygjg=; b=hMNytTxGGvIZBXoxEDH5qtbvbupuUYn4ne5cKZpj826/gOxfj1AUNeN6HyYJKeUBBn +i4cy1iKaHiqpeRvkWN9mzG9gdv4bhIEKB7tWuys5jTT2Em2ivHTnpergpJtSUlDcz4q LBeWaER0GIqnEWlJh310l1KmFhQJFsWMRaXKScFycBDbNYfHY5Z/CDWgx0IVxLTNfMUy F/GFE/i3vLPkXolyj/ASWaD92V/1GJSiAxNTAcrIMuJ/k76pfVwkKLWe4mC+UnufA4EF S9oTG/99/XZ9OFtma0rrhS9+hyItcA16QjYXE4IXZNa/3l34L1N8D/I8iLZ/HrDFZX4I letQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725471676; x=1726076476; h=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=UZBuD8ujlpQgbSRbizirR+La9i0Qd++C4v9xqo3Ygjg=; b=poRRKZSrtvKCOeXxLl7MCwLPfyF+DroHJiWIr7ffiXSbyNMHiB1BL2OS0G2Zibg9Zh 7yWAxXQKwOR1fdq1bSjEkQMPB8PTH2R1Sg2yaVd0SWfF4Ax5vnLAVfK5JJ4RS1fO4GQU 1ZTH++8JsqXJocBKIk+Q3S2RUUsk7y3fLWib0ItrsYZY0a1VKr0NJNjY/6rtl6gjOtQQ s2RMkT3aTQddFMDlN5U2FN6ZXyHsJtcHDDPD1wJn6/IwP066DUg1hNaVXi952TTfPnd6 cAe6kla2nODcFaqTXSQMb5CR561wVnKjx65+ewuQ1nNgX0sM0Fg60QyR4FDbfB7cjqfS yb8Q== X-Forwarded-Encrypted: i=1; AJvYcCWZSOZCY2rCxWlN8zNJu3qjQ1YsxjpJAf+MThdznBihLl42WRBo2Eim0ECGgp5XxzW8xalmW51yGg==@kvack.org X-Gm-Message-State: AOJu0YyVohbeICeMeLzbl+3oBDYh5/CcnRCiReWq3yXBh1o6vCWzd8Qp BsrCVTjnfrBIU2Cm68qSCEKMdTgMFb5jvln0w8buDiy34hKL8Zs29hI+/yk3ZqAqUGjKyRIKumK 0WlGcygYUB1MPtwiRGkJZrSlmpdhWb9HTfe5/ X-Google-Smtp-Source: AGHT+IEoDXI8FoMx8V9lgWzFfG23TZNEnZ2xUS6KrnJAvtWs0eqvlCYsIDcNRgoyvFYSEkuv8wZ+8GZJ8TUPESV3Hms= X-Received: by 2002:a2e:b8d6:0:b0:2ef:2ba5:d214 with SMTP id 38308e7fff4ca-2f6105c4facmr208540991fa.4.1725471674645; Wed, 04 Sep 2024 10:41:14 -0700 (PDT) MIME-Version: 1.0 References: <20240612124750.2220726-2-usamaarif642@gmail.com> <20240904055522.2376-1-21cnbao@gmail.com> In-Reply-To: From: Yosry Ahmed Date: Wed, 4 Sep 2024 10:40:37 -0700 Message-ID: Subject: Re: [PATCH v4 1/2] mm: store zero pages to be swapped out in a bitmap To: Barry Song <21cnbao@gmail.com> Cc: usamaarif642@gmail.com, akpm@linux-foundation.org, chengming.zhou@linux.dev, david@redhat.com, hannes@cmpxchg.org, hughd@google.com, kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, nphamcs@gmail.com, shakeel.butt@linux.dev, willy@infradead.org, ying.huang@intel.com, hanchuanhua@oppo.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: ABA57160003 X-Stat-Signature: dys66begof76a3zkknc58qzt4kkgmuzt X-Rspam-User: X-HE-Tag: 1725471677-967556 X-HE-Meta: U2FsdGVkX1/12GiEo3GQzf7Pv0atH6SvXhsFq8eGrgZGRXxkl5kkpvEOgCUsphhvZX4s61AfgknCICgb4/NkgqS4tSe+Vy4MCDqeLyhX2uPkcEk9hZsVCjkiuXhBUUwBUJNGH+x1lGDQauGY071UqqqUlttkcVtHmkZq4gEEMN0xODgK0B0ASvvtZ1dQhibzAQBbWpBZWBN3HslTFJVo1oddjl2iBJBz/i0ATOrWl0vCjh+qnUc9hJe2DTrDU4kxMCasvyB9nrUpmgtuQ48Tf7FsawlYeF57WBxxWvn63qS/GKGiRzl0JU3ovvLiB0j/hIXlvjwwU4cQt/3VuYCLVzhTlFw3FjkNbaPE+Us2eAV82febivX6ZZy4Ttt1asdUNpQHXs+/LVvwffoVeOmYO81ybcLpALSTyd4qBM0yYmN6662K8CRcuIKNrrn4p8Ds2lCZQn1WxD0vxsafoBRHobEsfxP7dwQBSW1QPyjixzfrA2n7YJkqrOIWjZ/hiadeGdpD7bXDKe+4/fe2L87oKncNA5Ic9gXVuu1rxC9N786DaYRP/cOS8B6o60qy1r9hQe+bcWBcediUdGIiIiX4k+y/T9j49jJlDl0+UR8Zft0fgrQdusg8Oc+uenJQCsi0xo12iZ6FdBw+hb+vpRLuKP4P7w1ve65pk0yUmgzOAbQ//6F47KMZVkTSEyLNZExkPjVrYt7+sMzUQGmCfkCuQxkmO/jLqt+SUCaPF0+LgzDc60O4c7UDu0ofG3mX3LeMvt+suLSQzp6BaMiwKHP/Ou/OuhbPtdiALW8dPkXWfcMVbSReFroY9OEW5ukzQzblKYrgV9MBGy6MoR73Tvlc4YdIR4I1uEvctHTN73ZvaA/z1eZjGw4WCl3GgoY1jiJHs6iaWhLLc8HdQ7nAHXiAsgpcPEpiDiMBJnrdHBa+uDChTsYAUI7yamCGZDQ8JVEJaMv06mudSlZs7BJReoD GrFOdlih nJIdPChfDuW9ay8Eb3nZB29eBZoM9D88sE08PB/Th8EjDkjKx75LL1tj7XjjgQzc8y43U0Jup3JYHbZp2p2vFktFgnNPkQ5Yd9YeRxZEDIy2RYL7EzevbTaA24BOz+s968nxhwELlm7PLf9TRiuhzFPFvFImPr7dnU6JuwIVsff8me2dH03cIPxM4OyaNygvHMTRI 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: [..] > > I understand the point of doing this to unblock the synchronous large > > folio swapin support work, but at some point we're gonna have to > > actually handle the cases where a large folio being swapped in is > > partially in the swap cache, zswap, the zeromap, etc. > > > > All these cases will need similar-ish handling, and I suspect we won't > > just skip swapping in large folios in all these cases. > > I agree that this is definitely the goal. `swap_read_folio()` should be a > dependable API that always returns reliable data, regardless of whether > `zeromap` or `zswap` is involved. Despite these issues, mTHP swap-in shouldn't > be held back. Significant efforts are underway to support large folios in > `zswap`, and progress is being made. Not to mention we've already allowed > `zeromap` to proceed, even though it doesn't support large folios. > > It's genuinely unfair to let the lack of mTHP support in `zeromap` and > `zswap` hold swap-in hostage. Well, two points here: 1. I did not say that we should block the synchronous mTHP swapin work for this :) I said the next item on the TODO list for mTHP swapin support should be handling these cases. 2. I think two things are getting conflated here. Zswap needs to support mTHP swapin*. Zeromap already supports mTHPs AFAICT. What is truly, and is outside the scope of zswap/zeromap, is being able to support hybrid mTHP swapin. When swapping in an mTHP, the swapped entries can be on disk, in the swapcache, in zswap, or in the zeromap. Even if all these things support mTHPs individually, we essentially need support to form an mTHP from swap entries in different backends. That's what I meant. Actually if we have that, we may not really need mTHP swapin support in zswap, because we can just form the large folio in the swap layer from multiple zswap entries. > > Nonetheless, `zeromap` and `zswap` are distinct cases. With `zeromap`, we > permit almost all mTHP swap-ins, except for those rare situations where > small folios that were swapped out happen to have contiguous and aligned > swap slots. > > swapcache is another quite different story, since our user scenarios begin from > the simplest sync io on mobile phones, we don't quite care about swapcache. Right. The reason I bring this up is as I mentioned above, there is a common problem of forming large folios from different sources, which includes the swap cache. The fact that synchronous swapin does not use the swapcache was a happy coincidence for you, as you can add support mTHP swapins without handling this case yet ;)