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 901C5C61DB2 for ; Mon, 9 Jun 2025 08:36:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1D896B009A; Mon, 9 Jun 2025 04:36:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EF4576B009B; Mon, 9 Jun 2025 04:36:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E31F76B009C; Mon, 9 Jun 2025 04:36:49 -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 C4FF66B009A for ; Mon, 9 Jun 2025 04:36:49 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 63242C1710 for ; Mon, 9 Jun 2025 08:36:49 +0000 (UTC) X-FDA: 83535206538.07.6F5A635 Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf17.hostedemail.com (Postfix) with ESMTP id 4D9404000F for ; Mon, 9 Jun 2025 08:36:47 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="QpyMs7/o"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749458207; a=rsa-sha256; cv=none; b=7snsDtTNcKnwhNd8xZbQagOWAIDzNFtaBoc2AD+uElhVLGSH5W38YtnGag4zXXMEGo24Ph mtTh0+0wfMDJN9L+qcw47fd2QNsIjmg2fOf2lmZZ5rVeMJEAcdf+YjBl1LxzUpPmUJinoG 9FH1BLp+SSShLLTgufy1LEpHtF1CprI= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="QpyMs7/o"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749458207; 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=bLzi7fkNUKLm1NFUE1B8JtpmPKupcs+RTSliBUZkKYw=; b=U+GGEWI3/q+Fq7v4uDPeqoX9CVLTObw2I5owV5k3fFPX6WVO/hbOt04me2s63Jc7MRkVUZ 0AuArGF1bfZKkVXfyZND3u7UO3iL1ZOHhAuLjsV6PQpY1D8X7ptUN1umDV8a/4OoRAL4tK PwMs9FdCSCcsyn1Py4OUqSkDIMkBh/0= Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-32a6f5cb6f9so19030061fa.2 for ; Mon, 09 Jun 2025 01:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749458206; x=1750063006; 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=bLzi7fkNUKLm1NFUE1B8JtpmPKupcs+RTSliBUZkKYw=; b=QpyMs7/oVX5tCCeWznElRNMIVITcs3Hy1b6JN3s3BsDGho7p4PnSenuvG6MAv4urF7 Nn8VBM/H45G9QwVv7HsA15Hj9AxaveEUhxK3M4BbXNyoYbh8Tx8Ud7m9Q4vW/WYpuS2E yMYJDSgeQmu+PDkP7oi4GO1ojDt4/FNHup16Zv0gOHes2JsoyoD8Hiznv4kqvZGyu2o0 OiMmIX5yHTUNslF4Z1wmg72KfhGBy4DWXIH/lLctMmwptkjTqaOT06h/FwrT9COGpPxH mBmxbIno0v7nxAQfADHi38XU8hrM7OZxzNeNlLK+zLdMS3HCErylIZiDIbHGP8uy+UFp JOVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749458206; x=1750063006; 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=bLzi7fkNUKLm1NFUE1B8JtpmPKupcs+RTSliBUZkKYw=; b=PzDzAknojJAcRi7JCBEf4tsH4tKKeFRJ6tanCrXd0GTPD4vgdmkSl1mWqmuGFPaLv+ Fcdr+3ZryQ5T2U1s7iQ8qoLLbY6htSUaKhbhU3cGeaNMQHQW/OSrfu9ekXa8GJH8ZEIY u9SuZ2C4JZofnp+BrpVgvkS3RfLACLd9DjhVC7C0yVMF+cqkSR/pr9KOMhVbgH2np5Uh XAlExLI5EB10ul3nLUPQrNICfRtRems7XJDcuiTS+hfgBuDay0zTIIlEaN6EV8VaE8zO pCP5CShcvRoSKz1YhwyZpMaFvtcpZ6gy/6biWyFDJ63fqVzXb58kdTN05D8CWxhVfnq4 LPsQ== X-Gm-Message-State: AOJu0YwqnO7OMkVGKR6QYN4t/XsvVTs05qu8PwLWPaVQKe6dBJyPPtKW q6Hg7NcTm+d0Mztj0zfGPnBxKFVHB7m6z/kKXGlJEOXXIVA3wyBNX/0OJIgx/tZzOkZYzc2GvDi C5kZkg0UFhryh0Yr28gwuZZzVjTNDBwc= X-Gm-Gg: ASbGnctUQIYF5MKJfLyxgyKFBCTpbwvV62kcxucrQ9xGwZYV5tPgRdqH48Jtv8khEbZ wWNo6xzr6Zjc8HaF3mTw5JAbuDmx66AQSwh9VhCLaKN4nAIkBHb4Rui+m8oC1ybocMMD6bYNZE9 GNXuEgInEL4AIMMB0mITHjdP+ij+hBr+aUmC/dyEXHSw== X-Google-Smtp-Source: AGHT+IGh894TOutDJ+yYWqn0fKVtXB7CWf9dsr1yJMZL1VvZK7zfESmiug7tJSAkL3q8fdEnsS2Bf443sA42klfDmdA= X-Received: by 2002:a2e:be20:0:b0:32a:739d:fad with SMTP id 38308e7fff4ca-32adfd43234mr34711291fa.36.1749458205221; Mon, 09 Jun 2025 01:36:45 -0700 (PDT) MIME-Version: 1.0 References: <20250608192713.95875-1-ryncsn@gmail.com> <36f52466-071a-4efb-adc2-8514b11f120c@linux.alibaba.com> In-Reply-To: <36f52466-071a-4efb-adc2-8514b11f120c@linux.alibaba.com> From: Kairui Song Date: Mon, 9 Jun 2025 16:36:27 +0800 X-Gm-Features: AX0GCFukoYe3lPMV878LXiNa2Z7NA0RD89DuQGcCeXScy3od6gKXTvbWZSg57aA Message-ID: Subject: Re: [PATCH] mm/shmem, swap: fix softlockup with mTHP swapin To: Baolin Wang Cc: linux-mm@kvack.org, Andrew Morton , Hugh Dickins , Kemeng Shi , Chris Li , Nhat Pham , Baoquan He , Barry Song , Usama Arif , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4D9404000F X-Stat-Signature: 41uqsk56xh6we1j8xwwegfj3666pdkod X-Rspam-User: X-HE-Tag: 1749458207-128074 X-HE-Meta: U2FsdGVkX1+bhJrw9OjArHQg9kD6HPqY8cjnO8EnK/9n3nGQ8wfMmp6ci6CXTH3l6jJF1Fk3csNq8jeNN+kcUQKMxgFHjC7dOnTXLlEXeyKJRit+2F1U1mcaPLqimYJo7WY+Ui1EqqzRUBTGd0tQ3lTYonLQ42NXBXktsEGUs7zHVErbhUo5LuIQc4KqnOwHdumEvPTzpN5QPiV5aMP0swBr/8jM32gYrBlZohPxtY8iWnnXkrsq13fM6t2vZ2uFvPT9aWiGheB8Daq96mK5PtnMAXk3C4xUms7ADApyD/7VZqRlGGkHEnIGzJ7/anQGaln04g1kfNepSB7bKZp/nJeC5PSODzZJAY+kjZk9fBlX86sWtw8eXuZOD3oOj4NnqA1l94JZqXDdBp73D5NFv80fx1rhlc8nOst71+YuuPDa31Fw8HcpYiuA+j/HqtaLHVorL/+Rw1g6ydg30WyVQBYdjlHWwfdRKdd3PHD2Wp3RqLoiZ3obnDLEjrx+XukGa2XWOnKvWYT57s9MkXkkZz/1D9JkiwV/1aHdFA5RbBOf5nOcrWOszNhnC7ABnG6+CVU9uE6cUQZ/v9suo74aOxm+7m/+re6HrWBy9mharl/dDcFW9de8cZcw9riRDhIGQYCl7ufnsDQ7Bfzw4SgKkw1MdhlG6xvBFZjCnpz/xfHt/jJu2s1AEeG44qitzhmTso+BYburzTzHn85jcOxA8ZKPj3HH3VOOnX8Rajq60AlS79X28CHIGR7ahu7/rVS/sxYQBVVeM2rgQ5NUovpJeY8eGpH8b6D5xsgWWIvFTc3xOygsusGk8iD/VVzBA2YU+Bgp9WD5Ki6/KOYiXJ6LdwWb7LLmgmJLcBXAtUJEE/h/KG0RV0B1f0I9tGt7Y1Ku16Dd/YcRwPusxiTjqQ7jW1rYE3tOid7hdR3CQ5GN0P624h09uwSjIffyzUbGLV154HOoPJQOTfZlaF/UqAQ XyuNFDJ8 9nAa32EPdrjWvHk/6roQTv7HJOYliQ/g1OoqRV5zJUKbuuXP4GYXHKJjt/iKfI1oSZBtrjSViLZQQp1UY+QRTVeDkLqwGH9qkreO3s9cwlbLkIuP9F6jGLzP9KCjSkPdd+n+/WW0ihlztMAq0aNdy8zU9boefbUsl4gB0dQCJaKZhkStAMkFh+STOCy6FWT4Udqs6he0e1wf7TS9GsUXx4dRZxk36VU0F3dgE82nNkufED3yGTLlXUkEbQUNFYancnIjgjiZr7InbMED88s01tzrhf9M9NTBXpRj375jbw03f3/Cyrrz8VzA3KigJjta5mLH6j4lrtFTvmkiU5sObvepIoKSbv4tXf7EGWbU/6yQanJr3IgdOSABlqQ== 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 Mon, Jun 9, 2025 at 4:27=E2=80=AFPM Baolin Wang wrote: > On 2025/6/9 03:27, Kairui Song wrote: > > From: Kairui Song > > > > Following softlockup can be easily reproduced on my test machine with: > > > > echo always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enable= d > > swapon /dev/zram0 # zram0 is a 48G swap device > > mkdir -p /sys/fs/cgroup/memory/test > > echo 1G > /sys/fs/cgroup/test/memory.max > > echo $BASHPID > /sys/fs/cgroup/test/cgroup.procs > > while true; do > > dd if=3D/dev/zero of=3D/tmp/test.img bs=3D1M count=3D5120 > > cat /tmp/test.img > /dev/null > > rm /tmp/test.img > > done > > > > Then after a while: > > watchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787] > > Modules linked in: zram virtiofs > > CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G = L 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)=C2=B7 > > Tainted: [L]=3DSOFTLOCKUP > > Hardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015 > > RIP: 0010:mpol_shared_policy_lookup+0xd/0x70 > > Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90= 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <48> 8b 1f 48 = 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8 > > RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202 > > RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001 > > RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518 > > RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000 > > R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001 > > R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000 > > FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:00000000000= 00000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > PKRU: 55555554 > > Call Trace: > > > > shmem_alloc_folio+0x31/0xc0 > > shmem_swapin_folio+0x309/0xcf0 > > ? filemap_get_entry+0x117/0x1e0 > > ? xas_load+0xd/0xb0 > > ? filemap_get_entry+0x101/0x1e0 > > shmem_get_folio_gfp+0x2ed/0x5b0 > > shmem_file_read_iter+0x7f/0x2e0 > > vfs_read+0x252/0x330 > > ksys_read+0x68/0xf0 > > do_syscall_64+0x4c/0x1c0 > > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > RIP: 0033:0x7f03f9a46991 > > Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20= ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 = ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec > > RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 > > RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991 > > RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003 > > RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380 > > R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 > > R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000 > > > > > > The reason is simple, readahead brought some order 0 folio in swap > > cache, and the swapin mTHP folio being allocated is in confict with it, > > so swapcache_prepare fails and causes shmem_swap_alloc_folio to return > > -EEXIST, and shmem simply retries again and again causing this loop. > > If swapcache_prepare() fails and retries, the folio's order (order 0) > getting from swapcache will be different from the order stored in the > shmem mapping, so we will split the large swap entry by the following > logic in shmem_swapin_folio(). So I am not sure why causing a softlockup? > > } else if (order !=3D folio_order(folio)) { > /* > * Swap readahead may swap in order 0 folios into swapcac= he > * asynchronously, while the shmem mapping can still stor= es > * large swap entries. In such cases, we should split the > * large swap entry to prevent possible data corruption. > */ > split_order =3D shmem_split_large_entry(inode, index, swa= p, gfp); > if (split_order < 0) { > error =3D split_order; > goto failed; > } > > /* > * If the large swap entry has already been split, it is > * necessary to recalculate the new swap entry based on > * the old order alignment. > */ > if (split_order > 0) { > pgoff_t offset =3D index - round_down(index, 1 <<= split_order); > > swap =3D swp_entry(swp_type(swap), swp_offset(swa= p) + offset); > } > } For example if the swap entry is 0x0 in shmem with order 4 (so it corresponds to swap entries 0x0 - 0x10), and a order 0 folio is currently cached with swap entry 0xa, then shmem swapin will try to use a folio with order 4, that will always fails swapcache_prepare, but filemap/swapcache lookup use entry 0x0 will return NULL, causing a loop. > > > > > Fix it by applying a similar fix for anon mTHP swapin. > > > > The performance change is very slight, time of swapin 10g zero folios > > (test for 12 times): > > Before: 2.49s > > After: 2.52s > > > > Fixes: 1dd44c0af4fa1 ("mm: shmem: skip swapcache for swapin of synchron= ous swap device") > > Signed-off-by: Kairui Song > > > > --- > > > > I found this issue while doing a performance comparing of mm-new with > > swap table series [1] on top of mm-new. This issue no longer exists > > if the swap table series is applied, because it elimated both > > SWAP_HAS_CACHE and SWP_SYNCHRONOUS_IO swapin completely while improving > > the performance and simplify the code, and the race swapin is solved > > differently by then. > > > > (The zero map fix might still need to stay for a while, but could be > > optimized too later with swap table). > > I don't understand why adding zeromap changes, and should explain this > explicitly. To stay in consistency with anon mTHP swapin, swap_zeromap_batch have it's own comments that a hybird folio with zero and non-zero pages can't be brought back as a whole. I can mention that in the commit message.