Re: [PATCH 1/2] iommu/arm-smmu-v3: Replace sort_nonatomic() with sort()
Pranjal Shrivastava <[email protected]> Mon, 3 Aug 2026 13:37:16 +0000
| Newsgroups | dev.linux.lists.iommu,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Aug 03, 2026 at 01:35:52PM +0100, Robin Murphy wrote: > On 02/08/2026 6:45 pm, Nicolin Chen wrote: > > On Sun, Aug 02, 2026 at 10:23:48AM +0100, Will Deacon wrote: > > > On Thu, Jul 30, 2026 at 06:12:15PM +0000, Kuan-Wei Chiu wrote: > > > > @@ -4047,9 +4047,9 @@ static int arm_smmu_insert_master(struct arm_smmu_device *smmu, > > > > } > > > > /* Put the ids into order for sorted to_merge/to_unref arrays */ > > > > - sort_nonatomic(master->streams, master->num_streams, > > > > - sizeof(master->streams[0]), arm_smmu_stream_id_cmp, > > > > - NULL); > > > > + sort(master->streams, master->num_streams, > > > > + sizeof(master->streams[0]), arm_smmu_stream_id_cmp, > > > > + NULL); > > > > > > Makes sense to me. Nicolin, did you choose the nonatomic version > > > specifically? > > > > It's probably rare to have a large multi-stream array, so I think > > sort() would be fine. > > Yeah, probably 99% of the time the size of this array will be 1. An > exceptional value of "large" might be something like 64 for a massive > (non-PCI) DMA engine with separate read and write IDs per channel for no > good reason. > > If and when someone ever were to report RCU stalls here then we can first > ask them what the heck their client device is... and unless and until then I > wouldn't think it's worth worrying about. > +1. Agreed, it should be fine to use sort() here.. > Thanks, > Robin. > Thanks, Praan