Re: [PATCH 0/2] lib/sort: Clean up sort_nonatomic() and sort_r_nonatomic()

From: Kuan-Wei Chiu

Date: Thu Jul 30 2026 - 15:49:57 EST


+Cc maintainers/reviewers of kernel/trace/bpf_trace.c

On Thu, Jul 30, 2026 at 06:12:14PM +0000, Kuan-Wei Chiu wrote:
> Remove the sort_nonatomic() and sort_r_nonatomic() APIs from the kernel
> library.
>
> Currently, the arm-smmu-v3 driver is the sole in-tree user of
> sort_nonatomic(). Because the array size being sorted is small in

I just realized that I missed another in-tree user: sort_r_nonatomic()
is actually being used in kernel/trace/bpf_trace.c.

Looking at the bpf code, the array size there is bounded by
MAX_TRACING_MULTI_CNT, which is set to (1u << 20). I guess sorting an
array of this size in a single go could potentially cause scheduling
latency spikes on certain configurations if we don't yield the cpu.

Because of this, it seems my proposal to completely remove
sort_r_nonatomic() and sort_nonatomic() from the core library was
premature.

Please let me know if you think otherwise, or if there is any
alternative approach for check_dup_ids() that would allow us to safely
drop sort_r_nonatomic(). Otherwise, please disregard this series.

Regards,
Kuan-Wei

> practice, there is no real risk of triggering a soft lockup. Therefore,
> the periodic cond_resched() calls provided by the _nonatomic variant
> are unnecessary.
>
> With the only in-tree user updated, the _nonatomic APIs are no longer
> needed anywhere in the kernel. Removing them effectively drops the
> wrapper function and eliminates the may_schedule branch from the
> innermost loop of the core sorting logic, slightly simplifying the code.
>
> Kuan-Wei Chiu (2):
> iommu/arm-smmu-v3: Replace sort_nonatomic() with sort()
> Revert "lib/sort.c: add _nonatomic() variants with cond_resched()"
>
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 6 +-
> include/linux/sort.h | 11 --
> lib/sort.c | 110 ++++++--------------
> 3 files changed, 34 insertions(+), 93 deletions(-)
>
> --
> 2.55.0.508.g3f0d502094-goog
>