On 08/08/2022 18.38, Yury Norov wrote: > On Mon, Aug 08, 2022 at 01:42:54PM +0200, Thomas Gleixner wrote: >> On Sat, Aug 06 2022 at 10:30, Thomas Gleixner wrote: >>> On Mon, Jul 18 2022 at 12:28, Yury Norov wrote: >>> >>>> tick_check_preferred() calls cpumask_equal() even if >>>> curdev->cpumask == newdev->cpumask. Fix it. >>> >>> What's to fix here? It's a pointless operation in a slow path and all >>> your "fix' is doing is to make the code larger. > > Pointless operation in a slow path is still pointless. > >> In fact cpumask_equal() should have the ptr1 == ptr2 check, so you don't >> have to add it all over the place. > > This adds to the image size: > add/remove: 1/1 grow/shrink: 24/3 up/down: 507/-46 (461) > > The more important, cpumask shouldn't check parameters because this is > an internal function. This whole series point is about adding such checks > under DEBUG_BITMAP config, and not affecting general case. Yury, calling bitmap_equal (and by extension cpumask_equal) with something that happens in some cases to be the same pointer for both operands is not a bug. If you want to optimize that case, add a check in __bitmap_equal(), it will add a few bytes (maybe 2-4 instructions) to the kernel image, much less than what this whole series does by open-coding that check all over, and since it's comparing two registers, it won't in any way affect the performance of the case where the pointers are distinct. Rasmus
