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 252D6C10F16 for ; Mon, 6 May 2024 12:58:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8BD6B6B0085; Mon, 6 May 2024 08:58:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 86D596B0087; Mon, 6 May 2024 08:58:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 75C246B0089; Mon, 6 May 2024 08:58:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 594E66B0085 for ; Mon, 6 May 2024 08:58:35 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 04BD3160A0D for ; Mon, 6 May 2024 12:58:34 +0000 (UTC) X-FDA: 82087974990.21.05BFF06 Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) by imf19.hostedemail.com (Postfix) with ESMTP id E60871A000B for ; Mon, 6 May 2024 12:58:31 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NBQCial1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.170 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=1715000311; 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=yMEDKA2r/0kfL1be0rSeK9sjaBQ2sk31dP6B+oKhvyc=; b=SAhfrd/Crkl/jJh+NunB8T57aEdiqPQts+/2DoaWMtmVQ3bVKpxdE28qrm/PYQWWw7Hqel NbHlvOzpFBLjlJxiWkyuOzSQLFD7/v7M89Bn3uoCm2U4VsLx5NMIearyV/OecIttIxcoQ+ 46AzBlt8wUu0SanHzxTGZMSA9bKrnyA= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NBQCial1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715000312; a=rsa-sha256; cv=none; b=eKkFaZB+XiM8pcMQpU21SouaPj9Ck1BuTpjIOjkGCuRrHdOV1PyNFu/yZ4wD52swj54bdU vmeNzode1IJQQ+LrfoOsD1Ab8AVv8ykZWXQ25+y0NqmEp/DPTZzi3rXRH0uUPQQi50W3l3 a5x3VBIuWrunMOoTu6WNKdVYSBX+1ek= Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-4dcfba0cf35so547071e0c.1 for ; Mon, 06 May 2024 05:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715000311; x=1715605111; 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=yMEDKA2r/0kfL1be0rSeK9sjaBQ2sk31dP6B+oKhvyc=; b=NBQCial1g4VNyPKLKvGPd5N5Hb7Y4EaNzQqcfsNQZM78QNp9PiFpY92TRfsZgRZ9Vm ZX7+1jkzM0ext1wyYJK4HouZENeB3FVvE/8N/0g1OLmhSZg2w8aJk2U905+ULu/GFTBY sZmuhtt2jMuHbMPHnMpugCLDSi1w+m0uyecKh4Z8RAdgQL2bJ+O4yrVwu81fANPJ4lY7 kH8CJf2PCb2URZQ0RraC/h3zllfFYRkJL7+zaMHWa2b5bbW1Za7ZIitSBxQUkMSycbV0 NxuaR65m7fDEfH0yKjWDbHyP3lVwDVbgGIghJnkxZJuTd4MiYm57ZIqDoTjDKJc4iSR8 g9gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715000311; x=1715605111; 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=yMEDKA2r/0kfL1be0rSeK9sjaBQ2sk31dP6B+oKhvyc=; b=jYuxqLZiFPRvm0OQHDkMNxUEit6HfghM4DnePD7IeRkKAsyBO5XmmSqvk/+q8f66Vs OMde/JgTUPDHOh7nSVvvqjVXFUpAXLe9bPPuFGp56XBWRKu9ibAzMyHvsG74YQHQaltE hRuaYpfRbhrM3tuwfwJoRyGo7gt3fTQV5Dj3t8mBTcDWKPhK3EYOwCsCi/iiCXm/YIOo zv4Ic+uPOEuMXxSYR4b2R7uRweWshz1ocMJI8wXCq75Mm2s07n8w8mHZ2vTw9RCWZ1cT M4I8P1DiSyc7qpbfdy9gFl6f98rvf6ztvjjjc1ckUFETXLKHoRDm08GH2wBe+6wV/TYo G0QQ== X-Forwarded-Encrypted: i=1; AJvYcCVV5duinuN2iltiL0xQAspa+wZA3aDdj8g5PrMAqYdYDWzBhmkzKT+ZBiiWnxV87CvwR+W7hVxM3rtpy9kt3i0vc6E= X-Gm-Message-State: AOJu0YwQJeuRnHkGNhHe+hxSt8TYNthZzAuLop1jA1dG6soEw4t2/1wt oCo7/e3VYDyGD7ff1g5TtlIX9ohFabEwJs6Z5JGpc9/Np1aM1y7FxPtlm90WT5bNQzTkJJL534T ixI/pSnFFBKfifffyKmfYsRWACCs= X-Google-Smtp-Source: AGHT+IEgrUHg8vroUe/DxhaxUae5fr5W/MPFcn3eVDlE5IVIClXZqG3nR22jXYCIMkGDkB64W6N7Rr3Bmovncy4rnYY= X-Received: by 2002:a05:6122:1da1:b0:4d4:2069:eafb with SMTP id gg33-20020a0561221da100b004d42069eafbmr7018977vkb.9.1715000310716; Mon, 06 May 2024 05:58:30 -0700 (PDT) MIME-Version: 1.0 References: <20240503005023.174597-1-21cnbao@gmail.com> <20240503005023.174597-7-21cnbao@gmail.com> <0b4d4d4b-91d8-4fd5-af4e-aebe9ee08b89@arm.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 7 May 2024 00:58:19 +1200 Message-ID: Subject: Re: [PATCH v3 6/6] mm: swap: entirely map large folios found in swapcache To: David Hildenbrand Cc: Ryan Roberts , akpm@linux-foundation.org, linux-mm@kvack.org, baolin.wang@linux.alibaba.com, chrisl@kernel.org, hanchuanhua@oppo.com, hannes@cmpxchg.org, hughd@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yosryahmed@google.com, yuzhao@google.com, ziy@nvidia.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: uuamd81j6a9aei3p3wb3oihffu99i49j X-Rspamd-Queue-Id: E60871A000B X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1715000311-974403 X-HE-Meta: U2FsdGVkX1+rnpb0VK61xJHTq1nuPdwtqnnAhAli/AFain/coTxAdSsOV3UJp0DP696RefjcBwHcdB2PfDbEv4DQoUgtuI6j6caLS79Jc7lvs/FJ5lS5Vlwv+jV4OY2M9lT6SijkDLOt2eOaCUa0qZ8/aCfVZXqoX+0bwtR2accIPcIEmI5wZ5DNcY3D6zEqsNSgzfBtcyvRv97dQOBMHxU0qynKpSpDyaIhwQ+V3NPdEhiY0fEBpL8xb+vGf5KRwQn35GH5UpdI5dMWX3rsXwZn8+tWoby60BwoEpm6Zng4/UsMWv+DrYdAXVUh3Yvz59vkk9jTuA05BPp6Bl86/2WydsjLgGCzA0PCRJZsj7axqpsHX+wkdMVWDwiuzHVdn0IfXRxJB/eVIwWay7mkF5Wle3qM8T01IkRubklqJVSuR/BCY2E9w/K5xGISM1mh3rNNjtJu/gL/6bP7Pj6mB+KXdFEErdbO8uwFtQaDN6f/q48wHLymRX7saLOil39915cTCaI/QFfy7aAP7ROd/lFVV6Vrca1Qp4+7jaCFez1bxPnP95SwflPaBL+h/po6i4s4m72tSYpeIE/gzfJ4WZKfEahnqsL4nNjiNEE7v2w7kq/6jZ4MF7r9q0o/NUXLilKj9HP2wEKXvXSy3KDg3r00gKDjs8Sg+yqcXH6bQTvbUXypGKgBIYGspwlkf48g8ydBewRow2n4IlndqkuofQUlE9UNd9dt0rHd0o+FwoxCEn+IOCtI6gGjh3JC8QSRdV7abnuOArv0KQE25E57G1eN/qyW+o+r9OTowIsnNLquZBTq7txH6K7/zVlB7zdJLKxdGx1lMktUyCy3FfI6cIbLjFmxu1nWtRV126BVka/VQcIN4zbDKygnF0ooFM6V0Lfhu+BnIEIi7c24HfZVviOrHyaebE5nbMCqkmob81h4y54sVZhDH7MgtAKYwbTrLz17iZp/X8dLCRYWvj3 aMZ7TihB zLxQjKCVNHh9bICg9cr69JDfObHDltSKcTE+xh9/HxVJrBAf06LyAVKVV/wQ6EJFwyhD68sZfds85dAsZ+UwfU2t31KUy/rgDtQXDjNvi0MfvNwlxw96iyuHtBwwQYMyxUvbbi269nF07U/xo/fl2dNVp18jHuLj3RofqYYKrKFW61uttJLYsBmnZCuXqAtovuZXuhCuz8Mk8v5aHNUtdb82vnW/zB1MK0IdNsX7ivJ0WqoiYRW9IAPuXNk05Wn0WGb++YHqXiSpTTckItLvPb1W2JnoSWREf8/g1TcGUpuOOMQOaFnUu1AmlaCMryUrccx+jMBkNU411AYtwnW+QPA3D9kWMDnkLTxrvoOgq4IQ8wI3XSt0Jlhzuy5K4Xg8r7e+mOZmzx2ztjhl+wJPxCzlZCfys1beFdR6iu4RHebVbuVyFVUT/J76KeQNaPgvvoxBUIpVwUav/RJW9mDTDIeY0N9myAtYBA63r4M3ptm2aXrKRjTHUYzJW6WPj7DWOHF9MjHc9TMJXQyk= 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, May 7, 2024 at 12:38=E2=80=AFAM Barry Song <21cnbao@gmail.com> wrot= e: > > On Tue, May 7, 2024 at 12:07=E2=80=AFAM David Hildenbrand wrote: > > > > On 04.05.24 01:23, Barry Song wrote: > > > On Fri, May 3, 2024 at 6:50=E2=80=AFPM Ryan Roberts wrote: > > >> > > >> On 03/05/2024 01:50, Barry Song wrote: > > >>> From: Chuanhua Han > > >>> > > >>> When a large folio is found in the swapcache, the current implement= ation > > >>> requires calling do_swap_page() nr_pages times, resulting in nr_pag= es > > >>> page faults. This patch opts to map the entire large folio at once = to > > >>> minimize page faults. Additionally, redundant checks and early exit= s > > >>> for ARM64 MTE restoring are removed. > > >>> > > >>> Signed-off-by: Chuanhua Han > > >>> Co-developed-by: Barry Song > > >>> Signed-off-by: Barry Song > > >> > > >> With the suggested changes below: > > >> > > >> Reviewed-by: Ryan Roberts > > >> > > >>> --- > > >>> mm/memory.c | 60 ++++++++++++++++++++++++++++++++++++++++++------= ----- > > >>> 1 file changed, 48 insertions(+), 12 deletions(-) > > >>> > > >>> diff --git a/mm/memory.c b/mm/memory.c > > >>> index 22e7c33cc747..940fdbe69fa1 100644 > > >>> --- a/mm/memory.c > > >>> +++ b/mm/memory.c > > >>> @@ -3968,6 +3968,10 @@ vm_fault_t do_swap_page(struct vm_fault *vmf= ) > > >>> pte_t pte; > > >>> vm_fault_t ret =3D 0; > > >>> void *shadow =3D NULL; > > >>> + int nr_pages =3D 1; > > >>> + unsigned long page_idx =3D 0; > > >>> + unsigned long address =3D vmf->address; > > >>> + pte_t *ptep; > > >> > > >> nit: Personally I'd prefer all these to get initialised just before = the "if > > >> (folio_test_large()..." block below. That way it is clear they are f= resh (incase > > >> any logic between here and there makes an adjustment) and its clear = that they > > >> are only to be used after that block (the compiler will warn if usin= g an > > >> uninitialized value). > > > > > > right. I agree this will make the code more readable. > > > > > >> > > >>> > > >>> if (!pte_unmap_same(vmf)) > > >>> goto out; > > >>> @@ -4166,6 +4170,36 @@ vm_fault_t do_swap_page(struct vm_fault *vmf= ) > > >>> goto out_nomap; > > >>> } > > >>> > > >>> + ptep =3D vmf->pte; > > >>> + if (folio_test_large(folio) && folio_test_swapcache(folio)) { > > >>> + int nr =3D folio_nr_pages(folio); > > >>> + unsigned long idx =3D folio_page_idx(folio, page); > > >>> + unsigned long folio_start =3D vmf->address - idx * PA= GE_SIZE; > > >>> + unsigned long folio_end =3D folio_start + nr * PAGE_S= IZE; > > >>> + pte_t *folio_ptep; > > >>> + pte_t folio_pte; > > >>> + > > >>> + if (unlikely(folio_start < max(vmf->address & PMD_MAS= K, vma->vm_start))) > > >>> + goto check_folio; > > >>> + if (unlikely(folio_end > pmd_addr_end(vmf->address, v= ma->vm_end))) > > >>> + goto check_folio; > > >>> + > > >>> + folio_ptep =3D vmf->pte - idx; > > >>> + folio_pte =3D ptep_get(folio_ptep); > > >>> + if (!pte_same(folio_pte, pte_move_swp_offset(vmf->ori= g_pte, -idx)) || > > >>> + swap_pte_batch(folio_ptep, nr, folio_pte) !=3D nr= ) > > >>> + goto check_folio; > > >>> + > > >>> + page_idx =3D idx; > > >>> + address =3D folio_start; > > >>> + ptep =3D folio_ptep; > > >>> + nr_pages =3D nr; > > >>> + entry =3D folio->swap; > > >>> + page =3D &folio->page; > > >>> + } > > >>> + > > >>> +check_folio: > > >> > > >> Is this still the correct label name, given the checks are now above= the new > > >> block? Perhaps "one_page" or something like that? > > > > > > not quite sure about this, as the code after one_page can be multiple= _pages. > > > On the other hand, it seems we are really checking folio after "check= _folio" > > > :-) > > > > > > > > > BUG_ON(!folio_test_anon(folio) && folio_test_mappedtodisk(folio)); > > > BUG_ON(folio_test_anon(folio) && PageAnonExclusive(page)); > > > > > > /* > > > * Check under PT lock (to protect against concurrent fork() sharing > > > * the swap entry concurrently) for certainly exclusive pages. > > > */ > > > if (!folio_test_ksm(folio)) { > > > > > > > > >> > > >>> + > > >>> /* > > >>> * PG_anon_exclusive reuses PG_mappedtodisk for anon pages. = A swap pte > > >>> * must never point at an anonymous page in the swapcache th= at is > > >>> @@ -4225,12 +4259,13 @@ vm_fault_t do_swap_page(struct vm_fault *vm= f) > > >>> * We're already holding a reference on the page but haven't= mapped it > > >>> * yet. > > >>> */ > > >>> - swap_free_nr(entry, 1); > > >>> + swap_free_nr(entry, nr_pages); > > >>> if (should_try_to_free_swap(folio, vma, vmf->flags)) > > >>> folio_free_swap(folio); > > >>> > > >>> - inc_mm_counter(vma->vm_mm, MM_ANONPAGES); > > >>> - dec_mm_counter(vma->vm_mm, MM_SWAPENTS); > > >>> + folio_ref_add(folio, nr_pages - 1); > > >>> + add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages); > > >>> + add_mm_counter(vma->vm_mm, MM_SWAPENTS, -nr_pages); > > >>> pte =3D mk_pte(page, vma->vm_page_prot); > > >>> > > >>> /* > > >>> @@ -4240,34 +4275,35 @@ vm_fault_t do_swap_page(struct vm_fault *vm= f) > > >>> * exclusivity. > > >>> */ > > >>> if (!folio_test_ksm(folio) && > > >>> - (exclusive || folio_ref_count(folio) =3D=3D 1)) { > > >>> + (exclusive || (folio_ref_count(folio) =3D=3D nr_pages && > > >>> + folio_nr_pages(folio) =3D=3D nr_pages))) { > > >> > > >> I think in practice there is no change here? If nr_pages > 1 then th= e folio is > > >> in the swapcache, so there is an extra ref on it? I agree with the c= hange for > > >> robustness sake. Just checking my understanding. > > > > > > This is the code showing we are reusing/(mkwrite) a folio either > > > 1. we meet a small folio and we are the only one hitting the small fo= lio > > > 2. we meet a large folio and we are the only one hitting the large fo= lio > > > > > > any corner cases besides the above two seems difficult. for example, > > > > > > while we hit a large folio in swapcache but if we can't entirely map = it > > > (nr_pages=3D=3D1) due to partial unmap, we will have folio_ref_count(= folio) > > > =3D=3D nr_pages =3D=3D 1 > > > > No, there would be other references from the swapcache and > > folio_ref_count(folio) > 1. See my other reply. > > right. can be clearer by: Wait, do we still need folio_nr_pages(folio) =3D=3D nr_pages even if we use folio_ref_count(folio) =3D=3D 1 and moving folio_ref_add(folio, nr_pages - = 1)? one case is that we have a large folio with 16 PTEs, and we unmap 15 swap PTE entries, thus we have only one swap entry left. Then we hit the large folio in swapcache. but we have only one PTE thus we will map only one PTE. lacking folio_nr_pages(folio) =3D=3D nr_pages, we reuse t= he large folio for one PTE. with it, do_wp_page() will migrate the large folio to a small one? 1AM, tired and sleepy. not quite sure I am correct. I look forward to seeing your reply tomorrow morning :-) > > @@ -4263,7 +4264,6 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > if (should_try_to_free_swap(folio, vma, vmf->flags)) > folio_free_swap(folio); > > - folio_ref_add(folio, nr_pages - 1); > add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages); > add_mm_counter(vma->vm_mm, MM_SWAPENTS, -nr_pages); > pte =3D mk_pte(page, vma->vm_page_prot); > @@ -4275,14 +4275,14 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > * exclusivity. > */ > if (!folio_test_ksm(folio) && > - (exclusive || (folio_ref_count(folio) =3D=3D nr_pages && > - folio_nr_pages(folio) =3D=3D nr_pages))) { > + (exclusive || folio_ref_count(folio) =3D=3D 1)) { > if (vmf->flags & FAULT_FLAG_WRITE) { > pte =3D maybe_mkwrite(pte_mkdirty(pte), vma); > vmf->flags &=3D ~FAULT_FLAG_WRITE; > } > rmap_flags |=3D RMAP_EXCLUSIVE; > } > + folio_ref_add(folio, nr_pages - 1); > flush_icache_pages(vma, page, nr_pages); > if (pte_swp_soft_dirty(vmf->orig_pte)) > pte =3D pte_mksoft_dirty(pte); > > > > > > -- > > Cheers, > > > > David / dhildenb > >