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 07BE1C61CE7 for ; Sun, 8 Jun 2025 23:58:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 709426B007B; Sun, 8 Jun 2025 19:58:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B9CC6B0088; Sun, 8 Jun 2025 19:58:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AABB6B0089; Sun, 8 Jun 2025 19:58:05 -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 35CCB6B007B for ; Sun, 8 Jun 2025 19:58:05 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 75B25C02D3 for ; Sun, 8 Jun 2025 23:58:04 +0000 (UTC) X-FDA: 83533899288.20.8EECC9B Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf17.hostedemail.com (Postfix) with ESMTP id AE6FF4000A for ; Sun, 8 Jun 2025 23:58:02 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gztVfVQg; spf=pass (imf17.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 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=1749427082; 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=iGmH5ljuY513Q7oN1sZEkjkw4WvDdwuxctgU+jqBt18=; b=2ZoggArARheQruF1lA+gksY8FR9151AKPTrxGhodTE2WUBUseShWNbs89n72y1AuW3bes6 l+zkQxlmwFNDdeCxdXgN9i6tZjs95m+Y0vgEQRxYehA2AhxWlmJmWG248faXXKlBgSHrI2 tFcz3BvsB0LmiBn4GdEdPGZdGsJNuPQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gztVfVQg; spf=pass (imf17.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749427082; a=rsa-sha256; cv=none; b=6f3rsx2Ntnz40mACboalc+uhG5+JTtzlV2JZlYwrxy5bOce6vaYgFtxlcF7iJZusNC/Qa5 b2pDowe850cr2RM3CaxnDYweZVgPghNGkwklLi6eiVugvsbnhemvvt5PZA98sT1aDqrKL5 qjfeeshRlci0/JSLeI3/cnWqBk8sIaw= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-530fdcec60dso229029e0c.0 for ; Sun, 08 Jun 2025 16:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749427082; x=1750031882; 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=iGmH5ljuY513Q7oN1sZEkjkw4WvDdwuxctgU+jqBt18=; b=gztVfVQgmoJXB2jVT2hVQ8Ym+olcMxgRWLiGSIWdddCTCiAwyhoeL9I5uXOE4zQfmN R41l5iFOs+gxt43md3LV3KrgUVJ4yzWRr5EpUcMozTlCVY4fMK4wOtMxXOh9TVpV1x1h d3etDMJmNRTIG+TcVP0Sa6CQ8p4cuqAYFsxnDLLlP2ehCvl0GmdPU7etcrOitJDkfc3H lp1XSK0+Sp9AidBNoSyjEaJ6OGb+PPQgRn+nVJ23RyL3gwteY+O7o5bX0OPw16gAKHFU vtBzLObNUOu6zLLF0OGzie2ztglxJxnhTtjuTX6c0IvWcK2yr4X2VWrILbgHYa2uk1bv nwAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749427082; x=1750031882; 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=iGmH5ljuY513Q7oN1sZEkjkw4WvDdwuxctgU+jqBt18=; b=YzZoF2wgIWYM4CtNcXyadBKAVyWfjV/oG8lLF+mr5QQp8O4gaXqxHzNt8bQ1+JovQl FcHDbccYf+NQ6Strk2PBJB3BqAGqJCjqW7hny4affXbrmCayEK8muL10FFpWEQEdBT1L Y5te0e1y/1eiUe0yADZz1900xjToPJiCA6H8jt9MU0fnBIKaFYKwAaHMpS+0j5kwxs2D 1ESZ96jMtLGskdEgi78gDBmI4IbodjzIrYoDWnzqiPZA1PNX70MXAQR0fLcW9hmASCUL /B+EUGRCeDQ511s0du/8nE+hI5JncLGQ2z7K7WgboKzHqNbrVyxJLXAxzcYoXcA+COgi Lp4A== X-Gm-Message-State: AOJu0YwLYE0rH+MrpxGdFtwSR1V5F9RgaYlZ6wffRAHEe27CNR0NGYKU 71hEdLm8swDTGTeC+eL23zNXGhQueCIBMpe8Z96QIrdMJuv5on7PV4ctB/BNH7YLyFnZ93odOsO FY1VuwVdaqaWYGU1P9RRKvfg6spAIXVc= X-Gm-Gg: ASbGnctgMNDfbAP/3tVYMhoZoED9LKp3qtCdQ9VuaHfKkZg/KWUVT2vKwtz38yv4vMQ v3E2zvLnVi1+Ll/dRYoQNRJFLE1JvobKRGrKUyrzGQofYphBM6dK7eFDwuMWkSkVMxFGuhdBEga AndE9815z5yFIRJTO5ooupPpPTGOckLNka5SaIyNt0WgRoUdeHZuGcVr4= X-Google-Smtp-Source: AGHT+IHyYhYjhNPGYT7+MJcc3pDVXLQUEp31kNf1HcGDh9BBe5Dw8biv9DE9152RZLiLmZEOevEMDeEjmYciDnsJJ6A= X-Received: by 2002:a05:6122:1313:b0:530:5fe5:7ea4 with SMTP id 71dfb90a1353d-530e48cac7cmr9116549e0c.11.1749427081653; Sun, 08 Jun 2025 16:58:01 -0700 (PDT) MIME-Version: 1.0 References: <20250608192713.95875-1-ryncsn@gmail.com> In-Reply-To: <20250608192713.95875-1-ryncsn@gmail.com> From: Barry Song <21cnbao@gmail.com> Date: Mon, 9 Jun 2025 11:57:50 +1200 X-Gm-Features: AX0GCFtYdJBSCWbKG8V1Cn7s2VDARmRAoLxVqB4RKD2jr24r86XEJoL93eK_Ygk Message-ID: Subject: Re: [PATCH] mm/shmem, swap: fix softlockup with mTHP swapin To: Kairui Song Cc: linux-mm@kvack.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-Server: rspam01 X-Rspamd-Queue-Id: AE6FF4000A X-Stat-Signature: fs3ru7zgt5ojkijquret11swjh6nmu41 X-Rspam-User: X-HE-Tag: 1749427082-151177 X-HE-Meta: U2FsdGVkX1+Ps8RRSoeWxFYlxuaVOQhwgnLYMnuON/GY/4OykmVydJVGe6TNUCS1tM0DVYRkFEh9sfK3B/ivy23Iyu4Gvrvry84KorU99HuFGuP1uhl2z2bbE9YtPk3ptqaNzrL1azL0MtDG3qoAlnn/cig7OFNrL7XE4O0eXlBJZb3DkpJMxCcXlz91iNhwh0CXPiE0rhmaZQ5s7l+pLAre7d0dc51E+R7Vhfkmgpl4FMc1UOsVXi11cGQOPUeBFV6ZzMtBimIokQPeWeylhNjHwQ3SdnCegf/q5gHxeM+TxUZzrIE7hh1Myj2qshqk8qEDY+7LWjaVYWwzvWhD+cvOuReRzAlQR5v+cCP8LVRrBtZxTduwfnoMuKRvhPeBVOh9EwxOS1rZAcjR04HDwaiXK8o1riCzKAeH3RzKGl9sd5k8/HF8kbBDdpzeegl35K8uCVKffgKVYT+6MZ0MxCTKfhZ3F11VzmZyWTd8uea7oVfUzZvVgLBYyiHYcmFgFOKpaquJc/R5DBNH2eljcmMhSkCla3ybvVs7RHJixkguBdrRfB0c4MVKTMOcuCwGd67cFCQUD/lMs3q4Yc6mnh5MS8/bJrMA7qTpi3/7Z3ByHqIfy664ELp6WcvAEZSMnC+MHLLnl688su38KKCgAYZtRcBwIsm6puiQ9bpz1s+NAWISMZnN+xNhVeAqvJY67SE7+Kfx+PZ+ZLDBuyv8V3+rhwkYwVihaq14oqZcjWIvFkxNAhpGlL96kCpFcxoRPc+KBKB7ItVpQt0I+phBeId+1nPlD3LoJpP89SEJdAsJPc7uxthOGDWMHNUMvgMkgIUxNDotD1kyW5W/YnFrrbeKf+dD6OJqZhAhtATi9UWMyiPqu2H7xuJRDQQPtyVwCL1aLlufkvakiuEeoEacc+xb4biU25LNJlEo+TV42fFnytuMon259qN+/on0cYpwDW5+7WrnnPk41qu6AZU 6Au99Mwl ERbC/GAudCTWnQgdaNP9SLEfthaRvoaFjsThju92p5PfGg6TT5gCouuAze7N7ksZYHQIKGscdGRtEpUflWmMQVoLOhYlmBfp/fnEKBvHtX/iCBW9RpkudPv8SlL9iX7FsWxXYgw+qAQ4H/ptRoKFVdQAbKnRF9VMfk9MkGcC9xS3K0twvFt7eIq/oe0x4lR/8wlNMzbHG8pimGYM5tIpwntRYg+3v7g4wGXtoUD8hmhLK9N+Y5ZTvokxKSGGsFAAuABklRyI9zRbm4BY3XbNLab/FiIEDW8o/3Je1LTsjfvdSLhHHHzfwYON+6bklRP5uP8eAOXUy3qOua/moiseUWQEgjTqVC/nuUEo80zg8IwppnyBv7ZMU6Sts5bAmzNlWk+KDgzPFTxRRMJA= 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 7:27=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/enabled > 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 9= 0 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:0000000000000= 000 > 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 a= d 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. > > 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 synchronou= s 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). > > It will be good if the swap table series could get reviewed and merged > to avoid more fixes like this. SWAP_HAS_CACHE and SWP_SYNCHRONOUS_IO has > a history of causing many issues. I'll do a swap table rebase on top of > this fix, if this one is accepted. > > And for a comparision, swap in 10G into shmem: > > Before this patch: 2.49s > After this patch: 2.52s > After swap table: 2.37s (Removing SWAP_HAS_CACHE and SWP_SYNCHRONOUS_IO= , > still not in the best shape but looking good) > > Link: https://lore.kernel.org/linux-mm/20250514201729.48420-1-ryncsn@gmai= l.com/ [1] > > mm/memory.c | 20 -------------------- > mm/shmem.c | 12 +++++++++++- > mm/swap.h | 19 +++++++++++++++++++ > 3 files changed, 30 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, whic= h 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..484cd3043a78 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -1995,6 +1995,14 @@ static struct folio *shmem_swap_alloc_folio(struct= inode *inode, > */ > if (swapcache_prepare(entry, nr_pages)) { > folio_put(new); > + > + /* > + * A smaller folio is in the swap cache, mTHP swapin will= always fail > + * until it's gone. Return -EINVAL to fallback to order 0= . > + */ > + if (non_swapcache_batch(entry, nr_pages) !=3D nr_pages) > + return ERR_PTR(-EINVAL); > + We're doing this before swapcache_prepare() for mTHP swapin. Why does it happen after swapcache_prepare() in the shmem case? > return ERR_PTR(-EEXIST); > } > > @@ -2256,6 +2264,7 @@ static int shmem_swapin_folio(struct inode *inode, = 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 +2280,8 @@ static int shmem_swapin_folio(struct inode *inode, = 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() || > + nr_pages !=3D swap_zeromap_batch(swap, = nr_pages, NULL))) > fallback_order0 =3D true; I mean, why don't we reject large folios at this point instead? Because if we do the check here, we might end up with a small folio in swapcache afterward? > > /* Skip swapcache for synchronous device. */ > diff --git a/mm/swap.h b/mm/swap.h > index e87a0f19a0ee..2d8ce1102153 100644 > --- a/mm/swap.h > +++ b/mm/swap.h > @@ -108,6 +108,25 @@ static inline int swap_zeromap_batch(swp_entry_t ent= ry, int max_nr, > return find_next_bit(sis->zeromap, end, start) - start; > } > > +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 need = to > + * ensure all entries are not cached, otherwise, the mTHP folio w= ill > + * 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; > +} > + > #else /* CONFIG_SWAP */ > struct swap_iocb; > static inline void swap_read_folio(struct folio *folio, struct swap_iocb= **plug) > -- > 2.49.0 > Thanks Barry