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.
---
Changes in v3:
- Abandoned the idea of introducing a new list_sort_nonatomic() API.
- Removed the dummy cmp() hack.
- Dropped the cond_resched() calls from UBIFS.
- Split the changes into a 2-patch series.
- Dropped Zhihao Cheng's Reviewed-by tag due to the fundamental change.

Changes in v2:
- Dropped the u8 count rate-limiter in merge() and merge_final().
- Removed cond_resched() calls from UBIFS comparison callbacks.

v2: https://lore.kernel.org/lkml/20260317165905.1482256-1-visitorckw@gmail.com/
v1: https://lore.kernel.org/lkml/20260315193900.218737-1-visitorckw@gmail.com/

Kuan-Wei Chiu (2):
  ubifs: Remove unnecessary cond_resched() from list_sort() compare
  lib/list_sort: Remove dummy cmp() calls to speed up merge_final()

 fs/ubifs/gc.c     | 2 --
 fs/ubifs/replay.c | 1 -
 lib/list_sort.c   | 9 ---------
 3 files changed, 12 deletions(-)

-- 
2.53.0.959.g497ff81fa9-goog

On Fri, 20 Mar 2026 18:09:36 +0000 Kuan-Wei Chiu <visitorckw@gmail.com> wrote:

> 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.

Thanks.  AI review found a now-unused local, which I'll fix.

https://sashiko.dev/#/patchset/20260320180938.1827148-1-visitorckw@gmail.com