On Fri, Dec 11, 2020 at 05:50:39PM +0900, Levi Yun wrote: > We should have same iteration count when we walk the same bitmap > regardless of using find_next_bit or find_last_bit.
I didn't understand why is so (I mean "same", I think you rather talking about same order of amount of itterations). > When we run the find_bit_benchmark.ko, we sometime get > unmatched iterations count below: > > Start testing find_bit() with random-filled bitmap > [+...] find_next_bit: 875085 ns, 163755 iterations < > [+...] find_next_zero_bit: 865319 ns, 163926 iterations > [+...] find_last_bit: 611807 ns, 163756 iterations < > [+...] find_first_bit: 1601016 ns, 16335 iterations > [+...] find_next_and_bit: 400645 ns, 74040 iterations > [+...] > Start testing find_bit() with sparse bitmap > [+...] find_next_bit: 9942 ns, 654 iterations > [+...] find_next_zero_bit: 1678445 ns, 327027 iterations > [+...] find_last_bit: 7131 ns, 654 iterations > [+...] find_first_bit: 551383 ns, 654 iterations > [+...] find_next_and_bit: 3027 ns, 1 iterations > > Normally, this is happen when the last bit of bitmap was set. > > This patch fix the unmatched iterations count between > test_find_next_bit and test_find_last_bit. Can you provide before and after to compare? -- With Best Regards, Andy Shevchenko
