Hi Yury,
On Thu, Nov 9, 2017 at 3:07 PM, Yury Norov <yno...@caviumnetworks.com> wrote:
> find_bit functions are widely used in the kernel, including hot paths.
> This module tests performance of that functions in 2 typical scenarios:
> randomly filled bitmap with relatively equal distribution of set and
> cleared bits, and sparse bitmap which has 1 set bit for 500 cleared bits.
Thanks for your patch!
> On ThunderX machine:
>
> Start testing find_bit() with random-filled bitmap
> [1032111.632383] find_next_bit: 240043 cycles, 164062 iterations
> [1032111.647236] find_next_zero_bit: 312848 cycles, 163619 iterations
> [1032111.661585] find_last_bit: 193748 cycles, 164062 iterations
> [1032113.450517] find_first_bit: 177720874 cycles, 164062
> iterations
> [1032113.462930]
> Start testing find_bit() with sparse bitmap
> [1032113.477229] find_next_bit: 3633 cycles, 656 iterations
> [1032113.494281] find_next_zero_bit: 620399 cycles, 327025 iterations
> [1032113.506723] find_last_bit: 3038 cycles, 656 iterations
> [1032113.524485] find_first_bit: 691407 cycles, 656 iterations
That's what ends up in dmesg, but that's not what it prints on the console:
"\t" prints an ugly placeholder, as TABs are not supported.
> --- /dev/null
> +++ b/lib/test_find_bit.c
> @@ -0,0 +1,141 @@
> +static int __init test_find_first_bit(void *bitmap, unsigned long len)
> +{
> + unsigned long i, cnt;
> + cycles_t cycles;
> +
> + cycles = get_cycles();
get_cycles() returns zero on half of the architectures.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
