summaryrefslogtreecommitdiff
path: root/rust/kernel/interop/git@git.tavy.me:linux-stable.git
diff options
context:
space:
mode:
authorKuan-Wei Chiu <visitorckw@gmail.com>2026-03-20 18:09:37 +0000
committerAndrew Morton <akpm@linux-foundation.org>2026-04-02 23:36:22 -0700
commit237213776d0fd62487da513b55732cfb20f7eee8 (patch)
treefb30f70177e21759dd8d0ad002634e907ee22f11 /rust/kernel/interop/git@git.tavy.me:linux-stable.git
parentaf53e85ef797d45b364edf330eb008639b5c98c2 (diff)
ubifs: remove unnecessary cond_resched() from list_sort() compare
Patch series "lib/list_sort: Clean up list_sort() scheduling workarounds", v3. Historically, list_sort() included a hack in merge_final() that periodically invoked dummy cmp(priv, b, b) calls when merging highly unbalanced lists. This allowed the caller to invoke cond_resched() within their comparison callbacks to avoid soft lockups. However, an audit of the kernel tree shows that fs/ubifs/ has been the sole user of this mechanism. For all other generic list_sort() users, this results in wasted function calls and unnecessary overhead in a tight loop. Recent discussions and code inspection confirmed that the lists being sorted in UBIFS are bounded in size (a few thousand elements at most), and the comparison functions are extremely lightweight. Therefore, UBIFS does not actually need to rely on this mechanism. This patch (of 2): Historically, UBIFS embedded cond_resched() calls inside its list_sort() comparison callbacks (data_nodes_cmp, nondata_nodes_cmp, and replay_entries_cmp) to prevent soft lockups when sorting long lists. However, further inspection by Richard Weinberger reveals that these compare functions are extremely lightweight and do not perform any blocking MTD I/O. Furthermore, the lists being sorted are strictly bounded in size: - In the GC case, the list contains at most the number of nodes that fit into a single LEB. - In the replay case, the list spans across a few LEBs from the UBIFS journal, amounting to at most a few thousand elements. Since the compare functions are called a few thousand times at most, the overhead of frequent scheduling points is unjustified. Removing the cond_resched() calls simplifies the comparison logic and reduces unnecessary context switch checks during the sort. Link: https://lkml.kernel.org/r/20260320180938.1827148-1-visitorckw@gmail.com Link: https://lkml.kernel.org/r/20260320180938.1827148-2-visitorckw@gmail.com Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com> Acked-by: Richard Weinberger <richard@nod.at> Cc: Ching-Chun (Jim) Huang <jserv@ccns.ncku.edu.tw> Cc: Christoph Hellwig <hch@infradead.org> Cc: Mars Cheng <marscheng@google.com> Cc: Yu-Chun Lin <eleanor15x@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'rust/kernel/interop/git@git.tavy.me:linux-stable.git')
0 files changed, 0 insertions, 0 deletions