Re: [PATCH v2] lib/list_sort: introduce list_sort_nonatomic() and clean up scheduling workarounds

[Christoph Hellwig]

On Tue, Mar 17, 2026 at 04:59:05PM +0000, Kuan-Wei Chiu wrote:
> Historically, list_sort() implemented a hack in merge_final():
>     if (unlikely(!++count))
>         cmp(priv, b, b);
> 
> This was designed specifically so that callers could periodically
> invoke cond_resched() within their comparison functions when merging
> highly unbalanced lists.
> 
> However, an audit of the kernel tree reveals that only fs/ubifs/ relies
> on this mechanism. For the vast majority of list_sort() users (such as
> block layer IO schedulers and file systems), this results in completely
> wasted function calls. In the worst-case scenario (merging an already
> sorted list where 'a' is exhausted quickly), it results in
> approximately (N/2)/256 unnecessary cmp() calls.
> 
> To clean up this API, eliminate the overhead for generic users, and
> consolidate the scheduling logic:
> 1. Introduce list_sort_nonatomic(), which explicitly calls
>    cond_resched() within its inner merge loops.
> 2. Remove the dummy cmp(priv, b, b) fallback from standard list_sort(),
>    saving unnecessary function calls and improving determinism for all
>    other subsystems.
> 3. Convert the sole user (fs/ubifs/) to the new API and completely
>    remove cond_resched() from UBIFS's comparison callbacks, unpolluting
>    its comparison logic.
> 
> This change leaves the generic list_sort() completely free of
> scheduling hacks, simplifies UBIFS's callbacks, and ensures that legacy
> long-list sorting workloads remain safe from soft lockups on
> non-preemptible kernels.

As said before we really should not add the extra nonatomic API
and just do the right thing, and drop the cond_resched in ubifs
in a prep patch.