> We see its not the case, before this patch, irqs smp_allowed_list was > sequential, but after the patch this changes. > I think this has to do with cache locality effects, when tasks run on "wrong" > CPUs. If you want us to check perf data, we can run that.
Nice catch. However, if this is indeed a cache locality issue, I would expect the performance impact to be more consistent. The results show a 4% performance improvement at jobs=32, which seems to contradict that explanation. > Below patch[1] fixes the issue for us. Basically keep the cpu order if > resources are equal, meanwhile keeping the benefit of your patches for > clustering. Yes, this is related to stable sorting, such change can preserve the order.
