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 1AA47E7716C for ; Thu, 5 Dec 2024 03:56:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6FF576B0083; Wed, 4 Dec 2024 22:56:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6ACA66B0085; Wed, 4 Dec 2024 22:56:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 526E86B0088; Wed, 4 Dec 2024 22:56:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 331C96B0083 for ; Wed, 4 Dec 2024 22:56:03 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A35671C7FD7 for ; Thu, 5 Dec 2024 03:56:02 +0000 (UTC) X-FDA: 82859541450.08.6AA5BBE Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf18.hostedemail.com (Postfix) with ESMTP id E15571C0008 for ; Thu, 5 Dec 2024 03:55:53 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mFNcMUFp; spf=pass (imf18.hostedemail.com: domain of hughd@google.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=hughd@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=1733370953; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KaS94RJU8jQE4zbDalu4mOpsczw2CxPrCQFCEvn0DAY=; b=A42n1v/cL14RatX8sLefEVkNM4ZHkFL7sebHoQCQf2uYA7UV2ifu1502N6JXYy9YR9mTZA 5WVVs3z5JLcE4ZPzkudooI84zsHVlMGKNfq5Q03Ko67PMz/acyKa4z7ic1vH13MBFxJQt5 7csXrw8mUS4POppRWDEavb2Hkcl5akM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733370953; a=rsa-sha256; cv=none; b=lFrNSGpnpOA681vrYK6p3LgYXjbLbrad5Y4XGs/lX3RQ/D0d3aF2Qn4HTuWAhdeuJ1wUJg VaD0rxFfprFOGfXa/M5P8QP14Y03w1BMD1KmqmCgTUOOOuKRI8v6sbXbNXkPTxKuKL6V2+ AAz5oenZafTlLEoNLfRCk4AnO7laULo= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mFNcMUFp; spf=pass (imf18.hostedemail.com: domain of hughd@google.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-72590a998b4so1103752b3a.0 for ; Wed, 04 Dec 2024 19:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733370959; x=1733975759; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=KaS94RJU8jQE4zbDalu4mOpsczw2CxPrCQFCEvn0DAY=; b=mFNcMUFpFgKb2k38VVFsBEfdI1q1iuDSOMHQLRK7iATQURj5s5/XBCVqoW5VyM3n2q 2NJIlODjmNwKggE3HelPa3/p+7+Atg8YdzD7eEnq09zZgaflkDjjBHW0hCDXwrs2Hpoq zz2oDK+i4/eEdHIkyX60zmgEaaiUiTKjDpOIQPFQbEbZFRjYRTvJL24qjaOcPFDpsdBe DRyxBD1g2eOsBcsXhY6DBQAqIdhlgXCmUiU7mR1r8twNTxGZLnYAqAT/93l2Byf/fPgg Nibjd9cpcSY0yNpJiebcIrxv8pZzs3rhwBghGOcltkNvPmS0FKh7yFv7wh1jmrUn5KWL GcxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733370959; x=1733975759; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KaS94RJU8jQE4zbDalu4mOpsczw2CxPrCQFCEvn0DAY=; b=mAPYPMA7IgLRWAFeV9AFsxwSA0FRIjHBixtDArzihk0uWgUqF6TicCiqVnmS8ZHYeL UAZYoXHWYEBGASU591FVmSBSTK9mUHJH+KxPJpo+28l5tE1xBboxKxXyHHOlDb0Vf75K ndrV6GGs2Yd/Aog6E9heZVh3Y8f9fYHfpDP/aU2kdniVl5NII4K0D//2/27kPw0az2gK K+5mMbZDGKQuJBFSpZaMnzp9Y4Zbo3RLRBFX04K9pb2IkfzCMJDGldlfrhT764YQbHWo m7L5cOE+r1AQxmOCwvR/Lzqzn5uzCBWWy6KqXrIb7JG3ifSB93put1jwmkf7/o+kUuVB meew== X-Forwarded-Encrypted: i=1; AJvYcCXP3k0TlHKKtpEh06aU9BvIIN5WBZtLmI1kI68HvKXjzUb/BtAyzTyFexMglvPxfML/OAdQDrbSSA==@kvack.org X-Gm-Message-State: AOJu0YyqsEkWudyouHL7FRkPEfa6XSSsj/UK6lHN2vEh6R+3jkLwM3AB WXSYZzqsSWJSQ7r3VT6rNFhUmmJCfVMhyhcqnBqpmcvCCFi3rpVx9mOl+uZ7kQ== X-Gm-Gg: ASbGncvzOEDVgPBeT323AUotukgOGythOc3pZotSD0x2lJUeHeGih9IirZnpvoC7HMi 2XvqXOZAbLgDgBGn8DM0e75mnwM+iEkZC8olA6N564geVuMrB3vtZEIBwXIYpJZfBuVGPL0MPns MZDWOI9M+BcnP0hUmtQvJHUVUGFyzxN7TSvsNtUBkxif6ElyblNWchMbsoQGPfSP1OrEv29oa4b K1AnsPlk/ylpgJdtgQV3OoeyBPylyAg1o5XsfYCw+tejZrGGWaHKyulwK0YdX8Xuhx4iWjf4NmR junadymrqWGeOZcXThiVKgUZotdNy84vSw== X-Google-Smtp-Source: AGHT+IGOGICKTpJv+lod4fIH882GKhFZkf4XS/slws2UT32lMDVlhD+D8l/V5cEs9Jldpll5sTVlXA== X-Received: by 2002:a05:6a00:608a:b0:725:99cc:c9a1 with SMTP id d2e1a72fcca58-7259d2df0c3mr2266764b3a.0.1733370958982; Wed, 04 Dec 2024 19:55:58 -0800 (PST) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-725a2a17860sm275800b3a.90.2024.12.04.19.55.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Dec 2024 19:55:57 -0800 (PST) Date: Wed, 4 Dec 2024 19:55:47 -0800 (PST) From: Hugh Dickins To: Andrew Morton cc: liuye , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mel Gorman , Hugh Dickins , Yang Shi , Minchan Kim , Michal Hocko , Johannes Weiner , Bharata B Rao , Yu Zhao Subject: Re: [PATCH v2 RESEND] mm/vmscan: Fix hard LOCKUP in function isolate_lru_folios In-Reply-To: <20241129192228.6f08e74a555bedcad71d32f4@linux-foundation.org> Message-ID: References: <20240919021443.9170-1-liuye@kylinos.cn> <20241119060842.274072-1-liuye@kylinos.cn> <20241129192228.6f08e74a555bedcad71d32f4@linux-foundation.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1463770367-225718998-1733370957=:7673" X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E15571C0008 X-Stat-Signature: izd8apr11uidfyzuhz83hjnb4w15nksg X-Rspam-User: X-HE-Tag: 1733370953-141949 X-HE-Meta: U2FsdGVkX1/fhJqVS9Se7l9jRFs4ktCNK6bnY7xQV/KJmW/cRVWFZSYMT9IHaxtIKN0UDFvFhOeRqM5qo9o0BTy4WKR+1LAxSANlA17K45ZJtz+sj/5gR/Lmot1fM8qgljQXTYu2hjRaAH/zR8JH+mnws1iWlgzTJaOJhq8EKRlXYOd9nPxbZogSQUIZoNc4sDG9W2Uxd/N+9+SEWT9UNjQ0mWwkpcifpWwzGM2JH9WFX2ozAU/F1WU6kJfsLxS71imCT372MM6lLM02s48PV+fdsTSAO4kwFCRTSUO3hlaq+pU+KzUAFxm3/W3FCm8gijPCqS2qApWZuwODlWE3hIut1rFFIH3CnJY1ozER7wXP55EhPV9fGBMPhJGBw15tXk56ZB24At4SLzMNBlE0AG2DJW9Xzpg2mpcGCeyu6oLKJP+oFqxNozBVBxmrTSsplhGefVZ1qlOPjcDhyU74QTMDOa/kJUCNtCFwM8i37C61kxxoBKo5LPS1BzIzh/DkEUM5GFuxzC8ko7IVBP/R9ic1iS21gk1fSRwwYnPBTD1lXm5s8qVmy9exTFZ5uJ+nFm+TuDZgmdYujCy7ipgVlZ80PpWfdNJj18o9uJNCwSWEuT+qjTNavUUGe1zoFH5WhxrSbgSDcOZHSYZ/1OB/Q+FEKn7R+MgAofMeVPN57pym3wau1okb0jqwelOnVKrC3hyNNhyiMXQcTJgRsX0IgxJZExqkXyu88bAvgBH0LhNNqhutQPj/rUEN5qQawXGgWaZKiraBflQpcZ2fVGvNCVMsSmzXGDPldQz7Yabe5v8t7W2D/17wGn0/ytI8URngVnJ8AzmO9WIoahNdcj0J/1nbtCxKNR1mczcZx7Sbs7pKc9nHPfsxOybuIyorpIRmAsGg1zDKDpZ05e2YT7OqfZuCA2bdLOQetzsB98FoePh3n6AgKeZCLESKE1U98uEc+5oXTOPONuDWRI/LpNi WxtOCPJ8 lxKpEc4o6V7ho8Z+eBsDQZVCOEitiADwa2y0T/cmBGgCLsuhh419Tdm69lrnDsmHR2PFqNFnP/+z5dPA8FZXYU8MrbHdYWDhS7jiMhJ3mLDzJp83ZJPOJRx5f9UHFHJ2bWoJuUZoVEV+WvmRPatgZEKYPV7vVQoIAlyqSdgcE2z8HOi6QALaXEOpwLx+fd9ofKLW1Z78xaUL6n32KLWAPwpZo2rUkPC3PRqCjuRIKCSnOLMuqbw6BeAjuzKg4nXt3fmUu6AfdN4BWBloCCV8rzirdgykanQQVOxfc3ZtrAuF5GGZWSjMWFUogVt9TkjZwNRb2kJzuoHRbd2vSqbmyv8zVCvQxQlZxyKCeeWcIYfHnJnsRN+hFRAm+4dQuoWhUmRMEvWeA65jxV48iF4oK5FJWNTVhX188Ws0AyPg8kEZp/4LXMpmVNCUMTNI65UtbjnhMklK8Bv/+CVtmyypM5CIXOo1HmJ5DiGMSPHD2Tl0Q+y0= 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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463770367-225718998-1733370957=:7673 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 29 Nov 2024, Andrew Morton wrote: > On Tue, 19 Nov 2024 14:08:42 +0800 liuye wrote: >=20 > > This fixes the following hard lockup in function isolate_lru_folios > > when memory reclaim.If the LRU mostly contains ineligible folios > > May trigger watchdog. > >=20 > > watchdog: Watchdog detected hard LOCKUP on cpu 173 > > RIP: 0010:native_queued_spin_lock_slowpath+0x255/0x2a0 > > Call Trace: > > =09_raw_spin_lock_irqsave+0x31/0x40 > > =09folio_lruvec_lock_irqsave+0x5f/0x90 > > =09folio_batch_move_lru+0x91/0x150 > > =09lru_add_drain_per_cpu+0x1c/0x40 > > =09process_one_work+0x17d/0x350 > > =09worker_thread+0x27b/0x3a0 > > =09kthread+0xe8/0x120 > > =09ret_from_fork+0x34/0x50 > > =09ret_from_fork_asm+0x1b/0x30 > >=20 > > lruvec->lru_lock owner=EF=BC=9A > >=20 > > PID: 2865 TASK: ffff888139214d40 CPU: 40 COMMAND: "kswapd0" > > #0 [fffffe0000945e60] crash_nmi_callback at ffffffffa567a555 > > #1 [fffffe0000945e68] nmi_handle at ffffffffa563b171 > > #2 [fffffe0000945eb0] default_do_nmi at ffffffffa6575920 > > #3 [fffffe0000945ed0] exc_nmi at ffffffffa6575af4 > > #4 [fffffe0000945ef0] end_repeat_nmi at ffffffffa6601dde > > [exception RIP: isolate_lru_folios+403] > > RIP: ffffffffa597df53 RSP: ffffc90006fb7c28 RFLAGS: 00000002 > > RAX: 0000000000000001 RBX: ffffc90006fb7c60 RCX: ffffea04a2196f88 > > RDX: ffffc90006fb7c60 RSI: ffffc90006fb7c60 RDI: ffffea04a2197048 > > RBP: ffff88812cbd3010 R8: ffffea04a2197008 R9: 0000000000000001 > > R10: 0000000000000000 R11: 0000000000000001 R12: ffffea04a2197008 > > R13: ffffea04a2197048 R14: ffffc90006fb7de8 R15: 0000000003e3e937 > > ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 > > > > #5 [ffffc90006fb7c28] isolate_lru_folios at ffffffffa597df53 > > #6 [ffffc90006fb7cf8] shrink_active_list at ffffffffa597f788 > > #7 [ffffc90006fb7da8] balance_pgdat at ffffffffa5986db0 > > #8 [ffffc90006fb7ec0] kswapd at ffffffffa5987354 > > #9 [ffffc90006fb7ef8] kthread at ffffffffa5748238 > > crash> > >=20 > > Scenario: > > User processe are requesting a large amount of memory and keep page act= ive. > > Then a module continuously requests memory from ZONE_DMA32 area. > > Memory reclaim will be triggered due to ZONE_DMA32 watermark alarm reac= hed. > > However pages in the LRU(active_anon) list are mostly from > > the ZONE_NORMAL area. > >=20 > > Reproduce: > > Terminal 1: Construct to continuously increase pages active(anon). > > mkdir /tmp/memory > > mount -t tmpfs -o size=3D1024000M tmpfs /tmp/memory > > dd if=3D/dev/zero of=3D/tmp/memory/block bs=3D4M > > tail /tmp/memory/block > >=20 > > Terminal 2: > > vmstat -a 1 > > active will increase. > > procs ---memory--- ---swap-- ---io---- -system-- ---cpu--- ... > > r b swpd free inact active si so bi bo > > 1 0 0 1445623076 45898836 83646008 0 0 0 > > 1 0 0 1445623076 43450228 86094616 0 0 0 > > 1 0 0 1445623076 41003480 88541364 0 0 0 > > 1 0 0 1445623076 38557088 90987756 0 0 0 > > 1 0 0 1445623076 36109688 93435156 0 0 0 > > 1 0 0 1445619552 33663256 95881632 0 0 0 > > 1 0 0 1445619804 31217140 98327792 0 0 0 > > 1 0 0 1445619804 28769988 100774944 0 0 0 > > 1 0 0 1445619804 26322348 103222584 0 0 0 > > 1 0 0 1445619804 23875592 105669340 0 0 0 > >=20 > > cat /proc/meminfo | head > > Active(anon) increase. > > MemTotal: 1579941036 kB > > MemFree: 1445618500 kB > > MemAvailable: 1453013224 kB > > Buffers: 6516 kB > > Cached: 128653956 kB > > SwapCached: 0 kB > > Active: 118110812 kB > > Inactive: 11436620 kB > > Active(anon): 115345744 kB > > Inactive(anon): 945292 kB > >=20 > > When the Active(anon) is 115345744 kB, insmod module triggers > > the ZONE_DMA32 watermark. > >=20 > > perf record -e vmscan:mm_vmscan_lru_isolate -aR > > perf script > > isolate_mode=3D0 classzone=3D1 order=3D1 nr_requested=3D32 nr_scanned= =3D2 > > nr_skipped=3D2 nr_taken=3D0 lru=3Dactive_anon > > isolate_mode=3D0 classzone=3D1 order=3D1 nr_requested=3D32 nr_scanned= =3D0 > > nr_skipped=3D0 nr_taken=3D0 lru=3Dactive_anon > > isolate_mode=3D0 classzone=3D1 order=3D0 nr_requested=3D32 nr_scanned= =3D28835844 > > nr_skipped=3D28835844 nr_taken=3D0 lru=3Dactive_anon > > isolate_mode=3D0 classzone=3D1 order=3D1 nr_requested=3D32 nr_scanned= =3D28835844 > > nr_skipped=3D28835844 nr_taken=3D0 lru=3Dactive_anon > > isolate_mode=3D0 classzone=3D1 order=3D0 nr_requested=3D32 nr_scanned= =3D29 > > nr_skipped=3D29 nr_taken=3D0 lru=3Dactive_anon > > isolate_mode=3D0 classzone=3D1 order=3D0 nr_requested=3D32 nr_scanned= =3D0 > > nr_skipped=3D0 nr_taken=3D0 lru=3Dactive_anon > >=20 > > See nr_scanned=3D28835844. > > 28835844 * 4k =3D 115343376KB approximately equal to 115345744 kB. > >=20 > > If increase Active(anon) to 1000G then insmod module triggers > > the ZONE_DMA32 watermark. hard lockup will occur. > >=20 > > In my device nr_scanned =3D 0000000003e3e937 when hard lockup. > > Convert to memory size 0x0000000003e3e937 * 4KB =3D 261072092 KB. > >=20 > > [ffffc90006fb7c28] isolate_lru_folios at ffffffffa597df53 > > ffffc90006fb7c30: 0000000000000020 0000000000000000 > > ffffc90006fb7c40: ffffc90006fb7d40 ffff88812cbd3000 > > ffffc90006fb7c50: ffffc90006fb7d30 0000000106fb7de8 > > ffffc90006fb7c60: ffffea04a2197008 ffffea0006ed4a48 > > ffffc90006fb7c70: 0000000000000000 0000000000000000 > > ffffc90006fb7c80: 0000000000000000 0000000000000000 > > ffffc90006fb7c90: 0000000000000000 0000000000000000 > > ffffc90006fb7ca0: 0000000000000000 0000000003e3e937 > > ffffc90006fb7cb0: 0000000000000000 0000000000000000 > > ffffc90006fb7cc0: 8d7c0b56b7874b00 ffff88812cbd3000 > >=20 > > About the Fixes: > > Why did it take eight years to be discovered? I don't think it took eight years to be discovered: it was long known as a potential issue, but awkward to solve properly, and most of us have survived well enough in practice that we've never given the time to it. > >=20 > > The problem requires the following conditions to occur: > > 1. The device memory should be large enough. > > 2. Pages in the LRU(active_anon) list are mostly from the ZONE_NORMAL a= rea. > > 3. The memory in ZONE_DMA32 needs to reach the watermark. > >=20 > > If the memory is not large enough, or if the usage design of ZONE_DMA32 > > area memory is reasonable, this problem is difficult to detect. > >=20 > > notes: > > The problem is most likely to occur in ZONE_DMA32 and ZONE_NORMAL, > > but other suitable scenarios may also trigger the problem. > > > > Fixes: b2e18757f2c9 ("mm, vmscan: begin reclaiming pages on a per-node = basis") > > >=20 > Thanks. >=20 > This is old code. I agree on b2e18757f2c9 and thanks for digging that > out. I disagree. Although that commit is the root cause of what led to this hard lockup problem, I believe there was no such hard lockup in it: if I thought that this patch were a good fix, I would say Fixes: 791b48b64232 ("mm: vmscan: scan until it finds eligible pages") which allowed the previously SWAP_CLUSTER_MAX-limited scan to go skipping indefinitely while holding spinlock with interrupts disabled; which this patch here now limits to 32k, but that still seems way too many to me. And then after its 32k skips, it gives up and reclaims a few unsuitable folios instead, just so that it can return a non-0 number to the caller. Unlikely to find and reclaim the suitable folios that it's looking for: which, despite its faults, the unpatched code does manage to do. >=20 > I'll add a cc:stable and shall queue it for testing, pending review > from others (please). It may be that the -stable tree maintainers ask > for a backport of this change into pre-folio-conversion kernels. But > given the obscurity of the workload, I'm not sure this would be worth > doing. Opinions are sought? I think I've been Cc'ed because git blame fingered some nearby isolation cleanups from me: I'm not the best person to comment, but I would give this patch a NAK. If we are going to worry about this after seven years (and with MGLRU approaching), I'd say the issue needs a better approach. Liuye, please start by reverting 791b48b64232 (which seems to have been implemented at the wrong level, inviting this hard lockup), and then studying its commit message and fixing the OOM kills which it was trying to fix - if they still exist after all the intervening years of tweaks. Perhaps it's just a matter of adjusting get_scan_count() or shrink_lruvec()= , to be more persistent in the reclaim_idx high-skipping case. I'd have liked to suggest an actual patch, but that's beyond me. Thanks, Hugh >=20 > > --- a/include/linux/swap.h > > +++ b/include/linux/swap.h > > @@ -223,6 +223,7 @@ enum { > > }; > > =20 > > #define SWAP_CLUSTER_MAX 32UL > > +#define SWAP_CLUSTER_MAX_SKIPPED (SWAP_CLUSTER_MAX << 10) > > #define COMPACT_CLUSTER_MAX SWAP_CLUSTER_MAX > > =20 > > /* Bit flag in swap_map */ > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 28ba2b06fc7d..0bdfae413b4c 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -1657,6 +1657,7 @@ static unsigned long isolate_lru_folios(unsigned = long nr_to_scan, > > =09unsigned long nr_skipped[MAX_NR_ZONES] =3D { 0, }; > > =09unsigned long skipped =3D 0; > > =09unsigned long scan, total_scan, nr_pages; > > +=09unsigned long max_nr_skipped =3D 0; > > =09LIST_HEAD(folios_skipped); > > =20 > > =09total_scan =3D 0; > > @@ -1671,9 +1672,12 @@ static unsigned long isolate_lru_folios(unsigned= long nr_to_scan, > > =09=09nr_pages =3D folio_nr_pages(folio); > > =09=09total_scan +=3D nr_pages; > > =20 > > -=09=09if (folio_zonenum(folio) > sc->reclaim_idx) { > > +=09=09/* Using max_nr_skipped to prevent hard LOCKUP*/ > > +=09=09if (max_nr_skipped < SWAP_CLUSTER_MAX_SKIPPED && > > +=09=09 (folio_zonenum(folio) > sc->reclaim_idx)) { > > =09=09=09nr_skipped[folio_zonenum(folio)] +=3D nr_pages; > > =09=09=09move_to =3D &folios_skipped; > > +=09=09=09max_nr_skipped++; > > =09=09=09goto move; > > =09=09} > > =20 > > --=20 > > 2.25.1 ---1463770367-225718998-1733370957=:7673--