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