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 9031FC02196 for ; Mon, 3 Feb 2025 07:15:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F24DA6B0088; Mon, 3 Feb 2025 02:15:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ED3656B0089; Mon, 3 Feb 2025 02:15:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D74076B008A; Mon, 3 Feb 2025 02:15:14 -0500 (EST) 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 BC36A6B0088 for ; Mon, 3 Feb 2025 02:15:14 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2FAB9C24DB for ; Mon, 3 Feb 2025 07:15:14 +0000 (UTC) X-FDA: 83077772148.16.103BD68 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf04.hostedemail.com (Postfix) with ESMTP id 3BFBE4000B for ; Mon, 3 Feb 2025 07:15:12 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UhQcF8mG; spf=pass (imf04.hostedemail.com: domain of yuzhao@google.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=yuzhao@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=1738566912; 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=o4Q2C26T0K74YYtpMKkiUgCp9WgkXow2PCxFIgsZpR8=; b=vi00SjJM+Io/rOZFgORmk8V+EAUyCiCMC9bqK1O7CxqX+dK56KwjY5+9CVnzaLVWqddw4v TvpNdJs0kXV1VzuGsi2y1nXIRfwsAAFSGh5pnPAb/X1/XoqjcmLWKioEpKmA7HsHRv4BFG lNcchrwumUCj3loaYMmRyjvMufN2rH4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UhQcF8mG; spf=pass (imf04.hostedemail.com: domain of yuzhao@google.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738566912; a=rsa-sha256; cv=none; b=uZ7b4afkd4CAJsO1MblTbKVKH4+MSDUTpyMZ0iVE/6jf6/3YCqYjqhWL2QjH4u5pTZmjf4 J0rnWNtpTw5HRfnE+bTlhagpdAqLZCtD6RuOvbIBrIu7Wu0xer/P2Yp+JEJZP45Hptsgk+ QogTdZWbRXn/XRDEeNLoBmWTCB8SGpQ= Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-ab737e78900so25871366b.0 for ; Sun, 02 Feb 2025 23:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738566910; x=1739171710; 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=o4Q2C26T0K74YYtpMKkiUgCp9WgkXow2PCxFIgsZpR8=; b=UhQcF8mG/k2rwkMYnB2UXrEUEKzqd3RwKQA0qZEzrJS+7mbVZ17ISqBYV1gMfmVapF wDFjppwp6TKyF7ZV3aWklquqBiRmOI/V5FPRzXRIpohsQVeBtgWTy7XGXUgo84aZGXEF KK1vYr9iImL/6yDBkeFsuTBCj1VMGg3S/kFKXO3F2e6mj5OJ7w7e8eKTnkqFFetoul2u YleLOIBTY26MUviluqKOVTxIBXoBk1S+vsbgsDI9IXROjcZfRHrVra47XLFd5naRd+wN 1nNHvqyk7SVY0l6DgbZghh5c4YWVikcxTu4TnT5hExlMEvPsJswO/RLDqnNPbb6BAhco 2H9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738566910; x=1739171710; 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=o4Q2C26T0K74YYtpMKkiUgCp9WgkXow2PCxFIgsZpR8=; b=GSaC4Aifvmkj+g+Zcm4J1V4O2+7KJQ3H0iHj1l2J1kyqmsEL7CacLqNcL0e9iGbyi7 Puc6QSqfX6pF83qBo0Dru7pcIDYGYd8RZnCor31maQBxiVgNGjoJvZ6LZ3/LsMgViSBi N1xWvOYFMlXTcKVS6kFz3DYF9U2nVgBVHDnfkYxt9gHPof3nPjcrlD7Jz8QfRxRib279 aaKxxl2qnguAGdC1L37g6i4LOF8DsrO/bo8fyAq8Tq6/WeEb56TUIrX/lftgTf6Fke1d 8XP7DnIVUIIiz4RgswMk7LwFQ0C8kAQEOQCLwCGfXAOVnBzgbybRqBWhKBxKADEesNys AhHg== X-Forwarded-Encrypted: i=1; AJvYcCXnyE55tLj2flrOYVWOmjBnmD7scrWLcHlX+kkQtVUT0Sn5aFdS7ZY3HrDkDVLWIxL9y76evvub1w==@kvack.org X-Gm-Message-State: AOJu0YxairmZ+WUcbR1y1+qXrqJjFchMCZBA3XTUn2Xr3fRO/8o7kqvi 8VKme72kmsO9Xd5j1delU1l/p0m56O7O4VLDJjiHvHFxqMRRrN63yrC8syAGrpjb1SYksmb589E SYwF5ZVDgl3QdCdMZr+YCOFmY7rDFnW/t4+YL X-Gm-Gg: ASbGncvPjfNPeGtx9EYnzASRstLQNnF5emHv8P6QiqHIPD3H3p7W58aOmceXhHMdKIQ 8OoWuPnhm+06nAjH4nE4NcdAMGQGkAzhkfPiOSqUv46ZN8oXrmUC2EpaXOIhrzLapv/kjw7WtjP JiftpFgCBh4Ar4UXXGGfa8naCN7JvF X-Google-Smtp-Source: AGHT+IHdYYosvgmkyk0C8oZShVymubMByyKMeQ8cwNm/+8aabmGSqYwd9mo6bUikqVJ6ovwhEY68gP7+kn4UIYDAqqs= X-Received: by 2002:a17:907:7ba3:b0:ab6:8bc1:9b5a with SMTP id a640c23a62f3a-ab6cfda42bbmr2465753066b.41.1738566900382; Sun, 02 Feb 2025 23:15:00 -0800 (PST) MIME-Version: 1.0 References: <20250130100050.1868208-1-kirill.shutemov@linux.intel.com> <20250130100050.1868208-7-kirill.shutemov@linux.intel.com> In-Reply-To: From: Yu Zhao Date: Mon, 3 Feb 2025 00:14:23 -0700 X-Gm-Features: AWEUYZl7Aut54vM8LMQf8gmofutWUertOFMuqNs0Wcb_mrIfZVJF6RYYAJtQ1BU Message-ID: Subject: Re: [PATCHv3 06/11] mm/vmscan: Use PG_dropbehind instead of PG_reclaim To: Kairui Song , "Kirill A. Shutemov" Cc: Andrew Morton , "Matthew Wilcox (Oracle)" , Jens Axboe , "Jason A. Donenfeld" , Andi Shyti , Chengming Zhou , Christian Brauner , Christophe Leroy , Dan Carpenter , David Airlie , David Hildenbrand , Hao Ge , Jani Nikula , Johannes Weiner , Joonas Lahtinen , Josef Bacik , Masami Hiramatsu , Mathieu Desnoyers , Miklos Szeredi , Nhat Pham , Oscar Salvador , Ran Xiaokai , Rodrigo Vivi , Simona Vetter , Steven Rostedt , Tvrtko Ursulin , Vlastimil Babka , Yosry Ahmed , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3BFBE4000B X-Stat-Signature: cowkzxqeya39gx1mww4trsy9p4x97c7h X-Rspam-User: X-HE-Tag: 1738566912-759333 X-HE-Meta: U2FsdGVkX1/vhyHbaqEixHR2t8Ol3mqtD0rVbYvO0buvWaJIRLtg3vq1TUMWDVXu7wVul1bk0Jnj95l/MzsPLMAzo3ENYMw1wcAr7Ayaz0mRX7EpIVnj6xb2TWGBPSxL2Nmqw+yMGIl2JD123WKLR6eP9HSWSU81iEGehFShJlkRtGjeRuhY5A3mrmQTel/znhZWYug4djGKVWCxlnbSuC7bPGjq3wN/D5ZvEyCS7VbRs+sAvaOK62FQRlYI/nQu9ELJ8lIGFp5OxYEU8+ojQhIUMlKbPSzCJrMJzLK/hUdFUzxSVlt1RvgKPTYIHalgeZKNp0Mve0pfCtrAcXbgURChHOekc9tzk5F6h5061AmGu0wQG7p94DByZPnAJirW12YSMHcAiQXAf3bRhdCJPTuVOtYpeyO2cxWqfqEW60VQcjSEcyJEJQx8aBPsVW0rbrJuX4BH0NIPX9TgQwG/LnIxJL8e7KE2nh+l+hM1z+3Njc0KTgROGH4dVh+JA6NsulbOPohIIxDNWNVK5CVuE/ZG0UWsGo9Hf8bs70vX5PByTqSoE+JHIxh6RGX8UfpWPO8Xmrk/vL7GUfxtlVBg0G9fAdYm2VVdNvU3x1UM+3LLcIpPpsM5ij3e9412zzWyQZzjIXqZiUMuaMz/FnJnX6w58cY3kQ9x19F9bEoYH0nuIJZJuQCiMR76uA8A/M7MwDcXRY+EDUyQvvV+ys2Qgfc8cj3QPpXEJYabXJNgjsqhbzo7jTiiD4vFv/M2dcXkacLzmdnw5D2NRCmKdOysJGWgY8Rl0+Ax3JJgxogXgL7NMiDxzcHj0w2D8DApNf0BUjqGtw2hMrJRt8W9hCydl5AQW2AAPgsm/9vK6KX+w6PsAUs8CcnVw0h3zP+Bk1JMxHVwLRHOZv33qhLwxMpL2mMWwUt2cgL+xaYJ0wiYPd3/6Vs11F18ekxqbiMfakZIuWSoYTwkJed5KuulUmM Er+1o3Ve WG9pV3njkqku0JWEECU8VykKVgNaYy0mE4M2AD8AnFrxs/B7+ROoBVmaAn9Ha3tX1Z6uIHThJPupufDcNlF6GeXwkUaEZ8iO8xxwjqqCiVMRjd/LgLgUjcQtASA+djZ79MwU5uonDW3eKP4i1ow4h27qUhUnqf1dbunmzVXoISSKvOdHjk47fQk7A1frVMzl7JsAg+/Tt0H0OOPwKR/0E/uKildPE0AMYVzQtA6gTOdsTs7fY+IHhARvV/4V1ftqskNzFyWUHETuLCTlS12xXOA+LAcCzaSkJ3xvviGVSJwn711SOXR4Y1XbvaA== 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 Sat, Feb 1, 2025 at 1:02=E2=80=AFAM Kairui Song wrote= : > > On Thu, Jan 30, 2025 at 6:02=E2=80=AFPM Kirill A. Shutemov > wrote: > > > > The recently introduced PG_dropbehind allows for freeing folios > > immediately after writeback. Unlike PG_reclaim, it does not need vmscan > > to be involved to get the folio freed. > > > > Instead of using folio_set_reclaim(), use folio_set_dropbehind() in > > pageout(). > > > > It is safe to leave PG_dropbehind on the folio if, for some reason > > (bug?), the folio is not in a writeback state after ->writepage(). > > In these cases, the kernel had to clear PG_reclaim as it shared a page > > flag bit with PG_readahead. > > > > Signed-off-by: Kirill A. Shutemov > > Acked-by: David Hildenbrand > > --- > > mm/vmscan.c | 9 +++------ > > 1 file changed, 3 insertions(+), 6 deletions(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index bc1826020159..c97adb0fdaa4 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -692,19 +692,16 @@ static pageout_t pageout(struct folio *folio, str= uct address_space *mapping, > > if (shmem_mapping(mapping) && folio_test_large(folio)) > > wbc.list =3D folio_list; > > > > - folio_set_reclaim(folio); > > + folio_set_dropbehind(folio); > > + > > res =3D mapping->a_ops->writepage(&folio->page, &wbc); > > if (res < 0) > > handle_write_error(mapping, folio, res); > > if (res =3D=3D AOP_WRITEPAGE_ACTIVATE) { > > - folio_clear_reclaim(folio); > > + folio_clear_dropbehind(folio); > > return PAGE_ACTIVATE; > > } > > > > - if (!folio_test_writeback(folio)) { > > - /* synchronous write or broken a_ops? */ > > - folio_clear_reclaim(folio); > > - } > > trace_mm_vmscan_write_folio(folio); > > node_stat_add_folio(folio, NR_VMSCAN_WRITE); > > return PAGE_SUCCESS; > > -- > > 2.47.2 > > > > Hi, I'm seeing following panic with SWAP after this commit: > > [ 29.672319] Oops: general protection fault, probably for > non-canonical address 0xffff88909a3be3: 0000 [#1] PREEMPT SMP NOPTI > [ 29.675503] CPU: 82 UID: 0 PID: 5145 Comm: tar Kdump: loaded Not > tainted 6.13.0.ptch-g1fe9ea48ec98 #917 > [ 29.677508] Hardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015 > [ 29.678886] RIP: 0010:__lock_acquire+0x20/0x15d0 > [ 29.679891] Code: 90 90 90 90 90 90 90 90 90 90 41 57 41 56 41 55 > 41 54 55 53 48 83 ec 30 8b 2d 10 ac f3 01 44 8b ac 24 88 00 00 00 85 > ed 74 64 <48> 8b 07 49 89 ff 48 3d 20 1d bf 83 74 56 8b 1d 8c f5 b1 01 > 41 89 > [ 29.683852] RSP: 0018:ffffc9000bea3148 EFLAGS: 00010002 > [ 29.684980] RAX: ffff8890874b2940 RBX: 0000000000000200 RCX: 000000000= 0000000 > [ 29.686510] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00ffff889= 09a3be3 > [ 29.688031] RBP: 0000000000000001 R08: 0000000000000001 R09: 000000000= 0000000 > [ 29.689561] R10: 0000000000000000 R11: 0000000000000020 R12: 00ffff889= 09a3be3 > [ 29.691087] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000= 0000000 > [ 29.692613] FS: 00007fa05c2824c0(0000) GS:ffff88a03fa80000(0000) > knlGS:0000000000000000 > [ 29.694339] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 29.695581] CR2: 000055f9abb7fc7d CR3: 00000010932f2002 CR4: 000000000= 0770eb0 > [ 29.697109] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000= 0000000 > [ 29.698637] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 000000000= 0000400 > [ 29.700161] PKRU: 55555554 > [ 29.700759] Call Trace: > [ 29.701296] > [ 29.701770] ? __die_body+0x1e/0x60 > [ 29.702540] ? die_addr+0x3c/0x60 > [ 29.703267] ? exc_general_protection+0x18f/0x3c0 > [ 29.704290] ? asm_exc_general_protection+0x26/0x30 > [ 29.705345] ? __lock_acquire+0x20/0x15d0 > [ 29.706215] ? lockdep_hardirqs_on_prepare+0xda/0x190 > [ 29.707304] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 > [ 29.708452] lock_acquire+0xbf/0x2e0 > [ 29.709229] ? folio_unmap_invalidate+0x12f/0x220 > [ 29.710257] ? __folio_end_writeback+0x15d/0x430 > [ 29.711260] ? __folio_end_writeback+0x116/0x430 > [ 29.712261] _raw_spin_lock+0x30/0x40 > [ 29.713064] ? folio_unmap_invalidate+0x12f/0x220 > [ 29.714076] folio_unmap_invalidate+0x12f/0x220 > [ 29.715058] folio_end_writeback+0xdf/0x190 > [ 29.715967] swap_writepage_bdev_sync+0x1e0/0x450 > [ 29.716994] ? __pfx_submit_bio_wait_endio+0x10/0x10 > [ 29.718074] swap_writepage+0x46b/0x6b0 > [ 29.718917] pageout+0x14b/0x360 > [ 29.719628] shrink_folio_list+0x67d/0xec0 > [ 29.720519] ? mark_held_locks+0x48/0x80 > [ 29.721375] evict_folios+0x2a7/0x9e0 > [ 29.722179] try_to_shrink_lruvec+0x19a/0x270 > [ 29.723130] lru_gen_shrink_lruvec+0x70/0xc0 > [ 29.724060] ? __lock_acquire+0x558/0x15d0 > [ 29.724954] shrink_lruvec+0x57/0x780 > [ 29.725754] ? find_held_lock+0x2d/0xa0 > [ 29.726588] ? rcu_read_unlock+0x17/0x60 > [ 29.727449] shrink_node+0x2ad/0x930 > [ 29.728229] do_try_to_free_pages+0xbd/0x4e0 > [ 29.729160] try_to_free_mem_cgroup_pages+0x123/0x2c0 > [ 29.730252] try_charge_memcg+0x222/0x660 > [ 29.731128] charge_memcg+0x3c/0x80 > [ 29.731888] __mem_cgroup_charge+0x30/0x70 > [ 29.732776] shmem_alloc_and_add_folio+0x1a5/0x480 > [ 29.733818] ? filemap_get_entry+0x155/0x390 > [ 29.734748] shmem_get_folio_gfp+0x28c/0x6c0 > [ 29.735680] shmem_write_begin+0x5a/0xc0 > [ 29.736535] generic_perform_write+0x12a/0x2e0 > [ 29.737503] shmem_file_write_iter+0x86/0x90 > [ 29.738428] vfs_write+0x364/0x530 > [ 29.739180] ksys_write+0x6c/0xe0 > [ 29.739906] do_syscall_64+0x66/0x140 > [ 29.740713] entry_SYSCALL_64_after_hwframe+0x76/0x7e > [ 29.741800] RIP: 0033:0x7fa05c439984 > [ 29.742584] Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f > 84 00 00 00 00 00 f3 0f 1e fa 80 3d c5 06 0e 00 00 74 13 b8 01 00 00 > 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 > 48 89 > [ 29.746542] RSP: 002b:00007ffece7720f8 EFLAGS: 00000202 ORIG_RAX: > 0000000000000001 > [ 29.748157] RAX: ffffffffffffffda RBX: 0000000000002800 RCX: 00007fa05= c439984 > [ 29.749682] RDX: 0000000000002800 RSI: 000055f9cfa08000 RDI: 000000000= 0000004 > [ 29.751216] RBP: 00007ffece772140 R08: 0000000000002800 R09: 000000000= 0000007 > [ 29.752743] R10: 0000000000000180 R11: 0000000000000202 R12: 000055f9c= fa08000 > [ 29.754262] R13: 0000000000000004 R14: 0000000000002800 R15: 000000000= 00009af > [ 29.755797] > [ 29.756285] Modules linked in: zram virtiofs > > I'm testing with PROVE_LOCKING on. It seems folio_unmap_invalidate is > called for swapcache folio and it doesn't work well, following PATCH > on top of mm-unstable seems fix it well: I think there is a bigger problem here. folio_end_reclaim_write() currently calls folio_unmap_invalidate() to remove the mapping, and that's very different from what __remove_mapping() does in the reclaim path: not only it breaks the swapcache case, the shadow entry is also lost.