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 B45E5C5B552 for ; Tue, 10 Jun 2025 12:10:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C32B6B0092; Tue, 10 Jun 2025 08:10:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 49AF06B0093; Tue, 10 Jun 2025 08:10:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B0906B0095; Tue, 10 Jun 2025 08:10:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1A00E6B0092 for ; Tue, 10 Jun 2025 08:10:04 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CC5E11A010E for ; Tue, 10 Jun 2025 12:10:03 +0000 (UTC) X-FDA: 83539372686.10.1812B19 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf02.hostedemail.com (Postfix) with ESMTP id 08CE080006 for ; Tue, 10 Jun 2025 12:10:01 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CTaSnfrM; spf=pass (imf02.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=ryncsn@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=1749557402; 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=+YL0ojihKPdNLv/xHN6QLm3jZrEwLGeSVmJyK9Ndi3o=; b=q88eOxJhLzd/pziUElKNw+L2DSRujRBKksJezYCiylhN8iEauQArn6k6FVyDD4mthQNFoq i4kmq7jBKw1Jjfy5EVIk1LOmub0rNPRCDcz7H1AI4sDK9ODKOkUjQREtbHzaby+HXqJNjL a81IpjW2jd+wP5lsvm2bEo5PLVxuVw0= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CTaSnfrM; spf=pass (imf02.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749557402; a=rsa-sha256; cv=none; b=bmvd8k+RImcgkGvpJshmi146KXgf+3w2B7fYA24eIwqExg6mDfIhWqnNLkFTgfYnPnO2al b+GP8wrVTDEXcHuDzTkBVS6QXTNeDLU7moibt+u5cgAmQ6xPHZLhyX3fjGLbNiKauIpzqh qkGvXghdbM7qjKB+jX8yBQKryJrJnDw= Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-54e98f73850so5742150e87.1 for ; Tue, 10 Jun 2025 05:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749557400; x=1750162200; 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=+YL0ojihKPdNLv/xHN6QLm3jZrEwLGeSVmJyK9Ndi3o=; b=CTaSnfrMsI/uqtcudJO7K/tOWUQQMROUK4hwi5YJWs2/Ol+dGV9h3/qYMnFxGVICS1 kstfZT+io8Znshlui6hAliixVH0nGtk8JUgGejjJSzRMKTxq8qaQc4fe12+9V06jfFld pUs/EjiBEwSoHx1MYdMycdJDHFTv3Gzm4T5mnGZ3iT/ZStpQVzmZlfB5AfXT7RNtO1RT XWZxsO3UppVUgaPpq5LfVenR0kTyOXiqrYArLEVglx2yhj3rhvUNy+tJYcxyS0/lkJga yMdNXNufPUgKAEwI83M2qrVZHSYk/ApcIuQ+QFTpjS7C6U/xTFtiobNtCvAmeE/rxTs1 Ve9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749557400; x=1750162200; 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=+YL0ojihKPdNLv/xHN6QLm3jZrEwLGeSVmJyK9Ndi3o=; b=EBi7Rdz2QnYpjwZdNzx1pDVDhi0k949DiQVIClTCx0XYNzYAFDvT45trzMSCVb0DN8 AqsFjRLy1R/vqdilhlzJqgr2Bx1XLdjGFp/xBT48XccxF6r9zf8oN+gF1UEfMbyKyAN+ bavsUrCki9lAO6+U6TAAkvztEE4oI8D1cL+ZVT8pOLYHFg7kVGsK0FYrhwPp84jnqwf9 06byufMWsF7ZNVnXSsecKWa0AM1Hf+eBu9uj7Nz7apll2MomoP3ldcDCD2N9GsHZHFY2 306JGXfbXGT96tbIeFOfyacn+DClBjpvsJjojM+odDMrAYmBgQbBgb0WFoFP8ujs/TBo OOWQ== X-Gm-Message-State: AOJu0YwZE6NVu2YSoKXdvBLBjczO4WxcW3WG+I+W41gn/J+bEY0wdsRp 0rjIVuXarA1yLYnxRWEz3xk+nRjPFR0I5ynx5nY7MlyV3OABzRFB2paC9Srqh2onl1D7KcPn9FG 90sjnUz8btCtwXr1OTWEa9wFXUQxCzyE= X-Gm-Gg: ASbGnctK77KPgL/IKxeRrMwEi822chaDUzZ7Wc+zJT7EuQLKQytuGpQD0N7ILVdWzLB d7kzZR2vUgok/Mrnq4QVnYTHNJ16TGgCZZjvKdWSltZ3moHyHHuMxwFupgT7SmSTTOf8et1FL01 jHki0wp72U/9NqPY2ha9KmmFfi4gcovUunvhX+42dXnBk= X-Google-Smtp-Source: AGHT+IEvdplytAWoEI0b8tB2VLoXPuB8Mj5MTg4zuYfiVUniSBpWeQl1NNfE+gjuO8yoACZHcvqvzk8X/2/Wce2M5F0= X-Received: by 2002:a05:651c:154b:b0:32a:864a:46eb with SMTP id 38308e7fff4ca-32adf98d1a9mr43570701fa.0.1749557399906; Tue, 10 Jun 2025 05:09:59 -0700 (PDT) MIME-Version: 1.0 References: <20250609171751.36305-1-ryncsn@gmail.com> In-Reply-To: From: Kairui Song Date: Tue, 10 Jun 2025 20:09:42 +0800 X-Gm-Features: AX0GCFvuHVV1WPPOy4MqkxoQsCRCqE4wKBt-y4BISmcrDOkwa27_2WBQbF-P6zA Message-ID: Subject: Re: [PATCH v2] mm/shmem, swap: fix softlockup with mTHP swapin To: Barry Song <21cnbao@gmail.com> Cc: linux-mm@kvack.org, stable@vger.kernel.org, Andrew Morton , Hugh Dickins , Baolin Wang , Kemeng Shi , Chris Li , Nhat Pham , Baoquan He , Usama Arif , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 08CE080006 X-Stat-Signature: aihp4bqhjoyakun5mnid3bisspmp1dmx X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1749557401-32032 X-HE-Meta: U2FsdGVkX1/rPgGRAIcoV2Mo6ahtLrqatJM374i6fdgoi6Tss0dK5hKl3HgAkGnHt5aPRLIToIu9DIClcE0MIW5LPf0JEgAnMdCBuipmaSx9IhQ+AvBLqr5I5W7NI8oSeM5NYU7s3iPPTi0Vo7ktH/g83BCPnmbsHAK9+V00s9ago4DyQ9/EF4oZFx3cH7Y479X5pF4MPesLvQpfj0iH5oYzGqGkJz6K2sHs4uGHi0d466URXRSn52OF6tn87Ww6CLXWqSsK/+/3k7LwcUdBwlSnbxDO7N6Ytf0usb51cr0fpmA5voVfUb2ibYIoWcVPUDQb1b8oL3fz/XqWhZ7WrzwymndiHSFTLsXnkF6rEydmpwZf+fQkZTpaOfa5gpAEP4cLb65IafO+FcZxUcSgM5/2RMYO2dBdXQoitCPvoOocHAEsy1QiHCWZEwgs0Txd+S1cY4q1oTvMmYxIor9ItpzGoFZJiO+IZOGnvesX9bLpTpIEbK0FKucsSyGdwZzT+bisj8sX2pkqeBLC0ZtZwphgnZIuai6mJZUMimGLVQQqeMbR3I48FulA8r2YXUA9I6phiQKHV1O7vXB98f8xk0FZENvyFkbfjcdNYvfeuerkIo/QpYTw7nK2ecdg3oWjI/3fFGIvPFxaF38s6OlgHzVpJxRplwW4GNrhpzXl+WVOlMtjlC7WOR9LJE4MnMoRAaa99pxE/7tZUhw9XJMuy2mrcvSYRE6JBePZouoftp1cPUJzT6snTciY2x+DSUmtA/69GYdkgID2/vFnEAQEWqK/U8wRKddcbD/SYaq9j0PoPD8rO8mNeKifaczYKxm/7dF/eX3inB6sttiofgjBCmS1uPe1vozNnCUFe4HlhnepWN211f5YyutgE4tdzZdWfMpuhOgUBQnL6L7IfsQwg2iXOTXbFphniyyyhCLCCTaII0536s5+JBX/hWxC3yHCuWq6cgMPMMQ= 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, Jun 10, 2025 at 5:17=E2=80=AFAM Barry Song <21cnbao@gmail.com> wrot= e: > > On Tue, Jun 10, 2025 at 5:24=E2=80=AFAM Kairui Song wr= ote: > > > > On Tue, Jun 10, 2025 at 1:18=E2=80=AFAM 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/enab= led > > > 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 4= 8 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:000000000= 0000000 > > > 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 f= 0 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: 000000000000000= 0 > > > 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 i= t, > > > so swapcache_prepare fails and causes shmem_swap_alloc_folio to retur= n > > > -EEXIST, and shmem simply retries again and again causing this loop. > > > > > > Fix it by applying a similar fix for anon mTHP swapin. > > > > > > The performance change is very slight, time of swapin 10g zero folios > > > with shmem (test for 12 times): > > > Before: 2.47s > > > After: 2.48s > > > > > > Fixes: 1dd44c0af4fa1 ("mm: shmem: skip swapcache for swapin of synchr= onous swap device") > > > Signed-off-by: Kairui Song > > Reviewed-by: Barry Song > > > > > > > --- > > > > > > V1: https://lore.kernel.org/linux-mm/20250608192713.95875-1-ryncsn@gm= ail.com/ > > > Updates: > > > - Move non_swapcache_batch check before swapcache_prepare, I was > > > expecting this could improve the performance, turns out it barely > > > helps and may even cause more overhead in some cases. [ Barry Song = ] > > > - Remove zero map check, no need to do that for shmem [ Barry Song, > > > Baolin Wang ] > > > - Fix build bot error. > > > > > > mm/memory.c | 20 -------------------- > > > mm/shmem.c | 4 +++- > > > mm/swap.h | 23 +++++++++++++++++++++++ > > > 3 files changed, 26 insertions(+), 21 deletions(-) > > > > > > diff --git a/mm/memory.c b/mm/memory.c > > > index 9ead7ab07e8e..3845ed068d74 100644 > > > --- a/mm/memory.c > > > +++ b/mm/memory.c > > > @@ -4313,26 +4313,6 @@ static struct folio *__alloc_swap_folio(struct= vm_fault *vmf) > > > } > > > > > > #ifdef CONFIG_TRANSPARENT_HUGEPAGE > > > -static inline int non_swapcache_batch(swp_entry_t entry, int max_nr) > > > -{ > > > - struct swap_info_struct *si =3D swp_swap_info(entry); > > > - pgoff_t offset =3D swp_offset(entry); > > > - int i; > > > - > > > - /* > > > - * While allocating a large folio and doing swap_read_folio, = which is > > > - * the case the being faulted pte doesn't have swapcache. We = need to > > > - * ensure all PTEs have no cache as well, otherwise, we might= go to > > > - * swap devices while the content is in swapcache. > > > - */ > > > - for (i =3D 0; i < max_nr; i++) { > > > - if ((si->swap_map[offset + i] & SWAP_HAS_CACHE)) > > > - return i; > > > - } > > > - > > > - return i; > > > -} > > > - > > > /* > > > * Check if the PTEs within a range are contiguous swap entries > > > * and have consistent swapcache, zeromap. > > > diff --git a/mm/shmem.c b/mm/shmem.c > > > index 73182e904f9c..a4fdfbd086f1 100644 > > > --- a/mm/shmem.c > > > +++ b/mm/shmem.c > > > @@ -2256,6 +2256,7 @@ static int shmem_swapin_folio(struct inode *ino= de, pgoff_t index, > > > folio =3D swap_cache_get_folio(swap, NULL, 0); > > > order =3D xa_get_order(&mapping->i_pages, index); > > > if (!folio) { > > > + int nr_pages =3D 1 << order; > > > bool fallback_order0 =3D false; > > > > > > /* Or update major stats only when swapin succeeds?? = */ > > > @@ -2271,7 +2272,8 @@ static int shmem_swapin_folio(struct inode *ino= de, pgoff_t index, > > > * to swapin order-0 folio, as well as for zswap case= . > > > */ > > > if (order > 0 && ((vma && unlikely(userfaultfd_armed(= vma))) || > > > - !zswap_never_enabled())) > > > + !zswap_never_enabled() || > > > + non_swapcache_batch(swap, nr_pages)= !=3D nr_pages)) > > > fallback_order0 =3D true; > > > > > > /* Skip swapcache for synchronous device. */ > > > diff --git a/mm/swap.h b/mm/swap.h > > > index e87a0f19a0ee..911ad5ff0f89 100644 > > > --- a/mm/swap.h > > > +++ b/mm/swap.h > > > @@ -108,6 +108,25 @@ static inline int swap_zeromap_batch(swp_entry_t= entry, int max_nr, > > > return find_next_bit(sis->zeromap, end, start) - star= t; > > > } > > > > > > +static inline int non_swapcache_batch(swp_entry_t entry, int max_nr) > > > +{ > > > + struct swap_info_struct *si =3D swp_swap_info(entry); > > > + pgoff_t offset =3D swp_offset(entry); > > > + int i; > > > + > > > + /* > > > + * While allocating a large folio and doing mTHP swapin, we n= eed to > > > + * ensure all entries are not cached, otherwise, the mTHP fol= io will > > > + * be in conflict with the folio in swap cache. > > > + */ > > > + for (i =3D 0; i < max_nr; i++) { > > > + if ((si->swap_map[offset + i] & SWAP_HAS_CACHE)) > > > + return i; > > > + } > > > + > > > + return i; > > > +} > > Nit: > This was previously under CONFIG_TRANSPARENT_HUGEPAGE, but is now > guarded by CONFIG_SWAP. I assume there's no performance impact, since > if (order > 0) would never be true on platforms where THP is > disabled, meaning non_swapcache_batch() would never be called? Yes, there is no performance overhead, order is always 0. But some clean up can be done later. The whole `order =3D xa_get_order` and related checks are not needed at all for !CONFIG_TRANSPARENT_HUGEPAGE. It's hard to optimize it out without shuffle too many code here, simply wrap non_swapcache_batch with CONFIG_TRANSPARENT_HUGEPAGE may cause more trouble for understanding the code and doesn't help much here, it's really the caller that should avoid the whole thing. That's not in the scope of a bugfix. I have a shmem xarray lookup optimization patch in the swap table series, now looking at it I found it might be useful for the clean up here. I'll check if I can send a clean up & optimize series first.