summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/python_version.py
diff options
context:
space:
mode:
authorChris Down <chris@chrisdown.name>2026-10-01 01:17:40 +0200
committerAndrew Morton <akpm@linux-foundation.org>2026-10-08 23:06:22 -0700
commit7c88180bd16655fd664d9b48dee76ed16c9f17f8 (patch)
tree7863c55bea358620d64056ef96b81c9c537bb402 /tools/lib/python/kdoc/python_version.py
parent4b0a0638b455f1800d0f07343194d4a77aaa884b (diff)
downloadlinux-next-7c88180bd16655fd664d9b48dee76ed16c9f17f8.tar.gz
linux-next-7c88180bd16655fd664d9b48dee76ed16c9f17f8.zip
mm: make swapoff interruptible when unusing mms/shmem
try_to_unuse() only checks for a pending signal between mms, and shmem_unuse() doesn't check at all. That means that once swapoff gets to a process or a shmem file with a lot swapped out, nothing can interrupt it until every last page of it has been read back in. Just as one example of where this can concretely show up, freezing tasks for suspend or hibernation has to wait for swapoff to notice the freezer's fake signal, and gives up after freeze_timeout_msecs (20 seconds by default). Here's a facetious example where one swaps out 2GiB of one process to a swap file on ext4, starts swapoff, and half a second later tries to freeze with pm_test=freezer. Writing to /sys/power/state then fails with EBUSY and this in dmesg: Freezing user space processes failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0): task:swapoff state:D stack:0 pid:3175 tgid:3175 ppid:2955 task_flags:0x400100 flags:0x00000419 Call trace: [...] io_schedule+0x44/0x70 folio_wait_bit_common+0x1ec/0x3d0 __folio_lock+0x24/0x40 unuse_pte_range+0x2d0/0x348 unuse_vma+0x158/0x248 unuse_mm+0xfc/0x150 try_to_unuse+0x104/0x3f8 __do_sys_swapoff+0x220/0x5d8 [...] The same goes for anything else that wants swapoff to stop, like an admin hitting ^C in a panic, of course. Prior to commit b56a2d8af914 ("mm: rid swapoff of quadratic complexity") try_to_unuse() was driven by find_next_to_unuse() which checks for a signal before every entry, so let's restore that behaviour. Just as an example of the improvements, here's how long freezing takes in the same test while swapoff is happening on my computer: before after 400MiB anon 8.925s 0.028s 400MiB shmem 1.639s 0.003s 2GiB anon failed after 20.003s 0.011s Link: https://lore.kernel.org/ar2YlFYjYUZ49ZA5@chrisdown.name Fixes: b56a2d8af914 ("mm: rid swapoff of quadratic complexity") Signed-off-by: Chris Down <chris@chrisdown.name> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org> Cc: Hugh Dickins <hughd@google.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Chris Li <chrisl@kernel.org> Cc: Kairui Song <kasong@tencent.com> Cc: Kemeng Shi <shikemeng@huaweicloud.com> Cc: Nhat Pham <nphamcs@gmail.com> Cc: Baoquan He <baoquan.he@linux.dev> Cc: Barry Song <baohua@kernel.org> Cc: Youngjun Park <youngjun.park@lge.com> Cc: Ying Huang <huang.ying.caritas@gmail.com> Cc: Kelley Nielsen <kelleynnn@gmail.com> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions