Re: [PATCH v4 0/2] Improve the performance of bitmap_find_next_zero_area_off()

[Yury Norov <yury.norov@gmail.com>]

On Mon, Jun 01, 2026 at 05:42:32PM +0800, Yi Sun wrote:
> Test code has been added to PATCH v2.
> No new APIs were introduced.
> 
> Testing with the test code showed a performance improvement
> of approximately 70%.

No, it's not. Your numbers show approximately 50% improvement for
the dense case, and approximately 2% slowdown for the sparse case. 
 
> Test result(random):
> 	orig_ns		orig_cnt	orig_average	new_ns		new_cnt		new_average	ratio
> test1	1388885		1154		1203		462923		1308		353		70.7%
> test2	1393616		1324		1052		736193		1212		607		42.3%
> test3	1391693		1216		1144		735808		1260		583		49%
> test4	1393231		1275		1092		742731		1402		529		51.6%
> test5	1390731		1260		1103		737231		1274		578		47.6%
> 
> Test result(sparse):
> 	orig_ns		orig_cnt	orig_average	new_ns		new_cnt		new_average	ratio
> test1	4496077		322477		13		2419462		322480		7		46.2%
> test2	7514731		322482		23		5785808		322476		17		26.1%
> test3	7490692		322493		23		7654423		322483		23		0%
> test4	7474500		322469		23		7628230		322483		23		0%
> test5	7452692		322481		23		7663116		322478		23		0%

The numbers look quite inconsistent. The first measurements are
significantly faster for almost all experiments. In the 'new sparse'
case the first run is 4 times faster than the others. And the ratio
0% is simply wrong.

Please, run the test on a real hardware, not virtualized. Please
built-in the test, so it's executed at boot time, or make sure you're
not running anything on parallel, like a GUI or networking.

I gave your code a brief test on my qemu, and I have 43% improvement
in the dense case, with p-value 0.001; and -8% for sparse bitmap,
with the p-value 0.044, still significant.

Overall not bad. But if some critical user has actually a sparse bitmap,
he'll be disappointed. There's not that many actual users of the
function. For v5, can you CC those from non-driver part, at least.

(The ARM GIC counts as the non-driver, I believe.)

> Test result explanation:
> Test both random and sparse five times.
> @orig_ns/cnt: Original version results.
> @new_ns/cnt: Optimized test results.
> @orig_average = orig_ns / orig_cnt
> @new_average = new_ns / new_cnt
> @ratio = (orig_average - new_average) / orig_average
> 
> The test results show that the optimized version
> improved performance in almost every test.
> 
> ---
> v3: https://lore.kernel.org/all/20260514090607.231387-1-yi.sun@unisoc.com
> - Based on Michał Nazarewicz's suggestion,
> code optimization was performed on PATCH v1.

We've got a special tag for it: Suggested-by. If the optimization is
still there, please use the tag. Can you point to that suggestion?

> v2: https://lore.kernel.org/all/20260514035644.4118050-1-yi.sun@unisoc.com
> - Do not introduce find_last_bit_from().
> 
> v1: https://lore.kernel.org/all/20260512040659.2992142-1-yi.sun@unisoc.com
> 
> 
> Yi Sun (2):
>   lib: bitmap: reduce the number of goto again in
>     bitmap_find_next_zero_area_off()
>   lib/bitmap: add tests for bitmap_find_next_zero_area_off()

The patch order is wrong. You'd introduce the test first, then the
improvement. I want to apply the 1st patch, then run the test, then
apply the 2nd patch, and run the test again to compare. The way you're
doing it now makes me reverting the patches, the useless work.

Thanks,
Yury

> 
>  lib/bitmap.c             | 10 +++++++---
>  lib/find_bit_benchmark.c | 17 +++++++++++++++++
>  lib/test_bitmap.c        | 28 ++++++++++++++++++++++++++++
>  3 files changed, 52 insertions(+), 3 deletions(-)
> 
> -- 
> 2.34.1