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 4B769C27C4F for ; Thu, 13 Jun 2024 10:56:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AEFAA6B009A; Thu, 13 Jun 2024 06:55:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A83376B009B; Thu, 13 Jun 2024 06:55:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F1F56B009C; Thu, 13 Jun 2024 06:55:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6E7BF6B009A for ; Thu, 13 Jun 2024 06:55:59 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0E40B1A0717 for ; Thu, 13 Jun 2024 10:55:59 +0000 (UTC) X-FDA: 82225560438.14.3ADE12D Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by imf24.hostedemail.com (Postfix) with ESMTP id E185A180007 for ; Thu, 13 Jun 2024 10:55:56 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EovvxU8P; spf=pass (imf24.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=21cnbao@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=1718276155; 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=LBfPg0Sf6+FiIihToqXtkFxEPPt7zTvyf0r/NMVh4q4=; b=Y6+INm2D48LYTkV+YspBoKTERZLZahGcC/JWjFmKs4FqXMPbKvenLGbcDioqlCfHgzRuUV XL/kmrJRrIJzzVQH8StK/eOHzKz96fEmD7TOf3Zroz9bV5sIVA6fT+LGNcZQhTGL1Q8/N4 OpeD87APuDq1sc/YxwJCmh/0e9Y8fwY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718276156; a=rsa-sha256; cv=none; b=oK2gxYSN/r8eojBoJgkkWyzHYbEaadjDL2HPHxaeCGUckGaRCQo88/5o3Q5OtoVQ1i84B7 YL3GaoWaBvdl0qK/iHHqgqpug1v+ufIyoM1emhg5WSWyJ8cUzAn98PWTmI2yafdvxDRjP+ BpjUkXz6oT3/tnIg7uf91G3WFEiQr4g= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EovvxU8P; spf=pass (imf24.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vs1-f52.google.com with SMTP id ada2fe7eead31-48d9fa0dfceso310129137.1 for ; Thu, 13 Jun 2024 03:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718276156; x=1718880956; 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=LBfPg0Sf6+FiIihToqXtkFxEPPt7zTvyf0r/NMVh4q4=; b=EovvxU8POSYQmYLf/qsD4yf1zqr/4p2PZV7C5qN0kzRSczl9lWfM+IMHW5dtaoOUX2 oRSB7PiZ5YLr3w8gZ6zRofYijNyN0WjBGHVf6PE26Qmb5QH7ySh7QZH79wmUlAyXkXpa Y9X9v3AX0Dh8EITF7iAASu5qww1+EmWxyRS/2pCXmEGaDwftCNGP5NCbzhQtqpYC8cjF mdg54Ey43Q+JBQR0UrLoV6gOPNlnroWpsYY2cCQT/vQCS9pbIxEA0ucfvbv/SSIVEf1/ OnHHsrourTS7bbICFUpRqltduuiAdk+0e/vmXDHG/Hwwpl4wPoc1p2ObhO0cSl/jhBAH gv8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718276156; x=1718880956; 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=LBfPg0Sf6+FiIihToqXtkFxEPPt7zTvyf0r/NMVh4q4=; b=XLG3NocJqDy5Yp4Ol8qPQS6H70ELWaxApjiQEh0luvwojoJedAR0jnx2blzXM6V9qy gT0103ebeCmFevso8W3diCwNsg/QjhVt2+K5T10L/vm4IVDeDuNXo3LD7f0l9yJt+1RW eA291IGpEshOs4o7gm5sMTNf5ZKBYDZs0OO5gC/Rg5Gr95iMQKdCpJfB87qfEKOpxPqs pVmhhDeaaOKCwyUX/rAr1EayWl4/QG/QO49IWS5kYvctlWkjWDW4ESzNb9CiorlyMw3Y 1ZdwOE4OVYl45MiEe+5zD98i7j4fCbWrJ7l/4674KEUS1qBwGSiTP2b8cVHAXWs0Wbrl l1kQ== X-Forwarded-Encrypted: i=1; AJvYcCUyeJzBMV1F9iUmFdMOuohDOGY8etRayrrIay9x5bUuTaHx2iYlT2rFix70L02BGA1xnqNVY12wtAkPBfCF77w2ahc= X-Gm-Message-State: AOJu0YwG74mhAyiRZhNz7lD8DHunTB9ohuv9N+95UiomT8Zxbc05q7uJ 4Ef/RlZgX/NvIzbEFkIJ0ImRpgENYnESIhHz7wG+eNJvT9gKYrxyZj9s47dUQ+IaF/y25w7aBrd 8S4xzqQS0ZsFrtWmvUPz3rSMYQDc= X-Google-Smtp-Source: AGHT+IFy8J6HgirDhGUDAbHi69VM2snxKddoGXz2BjvjuNFQJmuZsq1sGxEfpFWlBvC0mjuwkP3unHNmPM0m7/dAG1g= X-Received: by 2002:a67:f755:0:b0:48d:8b45:753e with SMTP id ada2fe7eead31-48d91db9d8fmr5037400137.11.1718276155873; Thu, 13 Jun 2024 03:55:55 -0700 (PDT) MIME-Version: 1.0 References: <20240613000721.23093-1-21cnbao@gmail.com> <20240613000721.23093-3-21cnbao@gmail.com> <77da1feb-2257-4545-9427-5729250ceb2b@redhat.com> <6ac8ff4d-7099-4547-9e76-528d14f171d8@redhat.com> In-Reply-To: <6ac8ff4d-7099-4547-9e76-528d14f171d8@redhat.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 13 Jun 2024 22:55:44 +1200 Message-ID: Subject: Re: [PATCH RFC 2/3] mm: do_swap_page: use folio_add_new_anon_rmap() if folio_test_anon(folio)==false To: David Hildenbrand Cc: akpm@linux-foundation.org, linux-mm@kvack.org, chrisl@kernel.org, linux-kernel@vger.kernel.org, mhocko@suse.com, ryan.roberts@arm.com, baolin.wang@linux.alibaba.com, yosryahmed@google.com, shy828301@gmail.com, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, ying.huang@intel.com, yuzhao@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E185A180007 X-Stat-Signature: s4r75je53jmbud8hc7n9y1gf1d14odky X-HE-Tag: 1718276156-500414 X-HE-Meta: U2FsdGVkX19DbfAkGgC9VmWPjE3/98QIYfTrl+7CY3I1nC1ksQS/c4Bm9g7SJ1ryxd7DVAaznNlYW1LtX6bSrQJxGXdBQXqrBO0FM+bVD0C8F/XoKb5NaeByXn1uMIjRdAtZ1OLLevANfn64TZh5TrBYG1N5BaBtF4wS1xLMoT6zRCc73P5YxO09ssGqiA8ANfC9vA1xrxmjntVkiM9oY8CrVUmc7TNU/0dMCFwRneWatALy3U9XD50NLVp9RUQ7YlOdA5geujoTY6jO9NyGpxBebwsYhQCdyMIo4q/rl1KuarcXin5JKPJZ6OHzG+R7Spsy15t0VPOzyx1pyud2HZ0qtRFwvFRN8OxjyNNN9e0MYggOi1FhHQOpn7I0NMjpXwuuJTJRVc10A25VNEzrOhuQriC2IVxzubTrC2rhHR7cculbDpTrUyixuPCIYLQ0pupThcPAU9enIWpSrJq6yXX5786c4zr5uYKp0iH5AF4+1dnIGwJz+An/IS97uEb8ikN+QmXDMK4SDPl9WHO+riyd6npCJQEQnDvc9phq08iuJKGL90/oJ9Tg7QQiqVYlpwcl0jZNiu39x9iRG4W6r86PSEGDxCvSJWXueY7OaBAucNl9SS3Kf2mpR6dHYL3NnsWEOiy4tzU84ctahzbj1JnmyzuXbv472FCgUD7/ox5tLxz4I7jRK06N7wxa2GAeEHhYE/0rEpvtxV+NrOWyor/2vNf0coFuIxkefBUyy3tVcvl508OcF0dYNuYDi6QUuZ446TKp2XYTrkzzdRN/63qxKiJy/dNMRsgDSdj3NeWck8uY7r+gW6yb9Hzjc+e7t6mZ/G+CZIembCa3mBdEkah5InwAULrIRA2wl+vlyI9rnH4mwcKDORWYErcBVH8f2IpZ0dJ9IkBitQpTbk1ZynBlSDC/jBgkgLRAaDe5G1Hii1BJaXuK2iRXVwo2S8FubUtUsaOutgv37CJgmeH oJ73oWVP P/zW+B/TDXzjGwLN8mjBYvAUXRch3pscqaJlrBpBXcROVG68TzBKMCFYlkgMf9f8x4Lxy7rp0dk+pwJQxk2sEQuFjpVFSJXZiH8xS2+NLaOyDBBRtBDwMJh8q7azj6Lw0de8Xqd97RB35Iqs0GtG2irJ0gib5aIh+/1xHZH4pgFuvDwo7c8YSXddzlc/R+quliYejN0Z01wg/Lo7lHOT115QjhukyllJTPNUhCzkSb0kW5zFLJ1S153k7o1dzEJ7Bl1s+elWSdyaXaYC012tKfp0ns5FnvB8oelVjfkShKYZzoLmNA+o1Db950vK9vTMCeQVjSMn9CFLk/4tl6ESGsXkh1xQ1zq+2QD7hqqgyWv7h5sWJjyKBHs5PDHHOEJheh8Zz+y4mSzA7oQp9R6qeUCYbHuwCwQot1YwIpUdnwkHq01MK78MBPAyH0x4kYTcyZ40GIA+qC/oQrP4M93kUm7fZ2UOxUfCig8Wfebb32dgfIBaqb2Ay7btkIMDv53/fckS+ 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 Thu, Jun 13, 2024 at 10:37=E2=80=AFPM David Hildenbrand wrote: > > On 13.06.24 11:58, Barry Song wrote: > > On Thu, Jun 13, 2024 at 9:23=E2=80=AFPM David Hildenbrand wrote: > >> > >> On 13.06.24 02:07, Barry Song wrote: > >>> From: Barry Song > >>> > >>> For the !folio_test_anon(folio) case, we can now invoke folio_add_new= _anon_rmap() > >>> with the rmap flags set to either EXCLUSIVE or non-EXCLUSIVE. This ac= tion will > >>> suppress the VM_WARN_ON_FOLIO check within __folio_add_anon_rmap() wh= ile initiating > >>> the process of bringing up mTHP swapin. > >>> > >>> static __always_inline void __folio_add_anon_rmap(struct folio *fo= lio, > >>> struct page *page, int nr_pages, struct vm_area_st= ruct *vma, > >>> unsigned long address, rmap_t flags, enum rmap_lev= el level) > >>> { > >>> ... > >>> if (unlikely(!folio_test_anon(folio))) { > >>> VM_WARN_ON_FOLIO(folio_test_large(folio) && > >>> level !=3D RMAP_LEVEL_PMD, folio)= ; > >>> } > >>> ... > >>> } > >>> > >>> It also enhances the code=E2=80=99s readability. > >>> > >>> Suggested-by: David Hildenbrand > >>> Signed-off-by: Barry Song > >>> --- > >>> mm/memory.c | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>> diff --git a/mm/memory.c b/mm/memory.c > >>> index 2f94921091fb..9c962f62f928 100644 > >>> --- a/mm/memory.c > >>> +++ b/mm/memory.c > >>> @@ -4339,6 +4339,8 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > >>> if (unlikely(folio !=3D swapcache && swapcache)) { > >>> folio_add_new_anon_rmap(folio, vma, address, RMAP_EXCL= USIVE); > >>> folio_add_lru_vma(folio, vma); > >>> + } else if (!folio_test_anon(folio)) { > >>> + folio_add_new_anon_rmap(folio, vma, address, rmap_flags= ); > >> > >> So, with large folio swapin, we would never end up here if any swp PTE > >> is !exclusive, because we would make sure to allocate a large folio on= ly > >> for suitable regions, correct? > >> > >> It can certainly happen during swapout + refault with large folios. Bu= t > >> there, we will always have folio_test_anon() still set and wouldn't ru= n > >> into this code path. > >> > >> (it will all be better with per-folio PAE bit, but that will take some > >> more time until I actually get to implement it properly, handling all > >> the nasty corner cases) > >> > >> Better add a comment regarding why we are sure that the complete thing > >> is exclusive (e.g., currently only small folios). > > > > No, patch 1/3 enables both cases to call folio_add_new_anon_rmap(). Cur= rently, > > small folios could be non-exclusive. I suppose your question is > > whether we should > > ensure that all pages within a mTHP have the same exclusivity status, > > rather than > > always being exclusive? > > We must never end up calling folio_add_new_anon_rmap(folio, vma, > address, RMAP_EXCLUSIVE) if part of the folio is non-exclusive. Agreed. > > I think we *may* call folio_add_new_anon_rmap(folio, vma, address, 0) if > part of the folio is exclusive [it go swapped out, so there cannot be > GUP references]. But, to be future proof (single PAE bit per folio), we > better avoid that on swapin if possible. > > For small folios, it's clear that it cannot be partially exclusive > (single page). Yes, for small folios, it is much simpler; they are either entirely exclusi= ve or entirely non-exclusive. For the initial swapin patch[1], which only supports SYNC-IO mTHP swapin, mTHP is always entirely exclusive. I am also considering non-SYNCHRONOUS_IO swapcache-based mTHP swapin but intend to start with the entirely exclusive cases. [1] https://lore.kernel.org/linux-mm/20240304081348.197341-6-21cnbao@gmail.= com/ > > We better comment why we obey to the above. Like > > "We currently ensure that new folios cannot be partially exclusive: they > are either fully exclusive or fully shared." > > -- > Cheers, > > David / dhildenb > Thanks Barry