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

[Kuan-Wei Chiu]

On Wed, Mar 18, 2026 at 11:07:51AM +0100, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
> > Von: "Christoph Hellwig" <hch@xxxxxxxxxxxxx>
> >> 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.
> 
> I think you are right. After inspecting UBIFS's usage of list_sort()
> I feel more confident that we can remove the calls to cond_resched()
> from the compare functions.
> 
> The compare functions are rather cheap, they don't do (blocking)
> MTD io.
> In the GC case each list contains at most as many UBIFS nodes you can
> stuff into a single LEB.
> The replay case is a little different, the replay list can contain
> elements from multiple LEBs. But the UBIFS journal is limited to
> a few LEBs, so the list is likely always at most a few thousand
> elements long.
> So, we always talk about calling the compare functions a few thousand
> times, not millions times.
> 
Great, thanks for verifying this.

I'll prepare a v3 to drop the cond_resched() calls from UBIFS's cmp(),
and remove the if(!++count) from list_sort().

Regards,
Kuan-Wei