> Can you please welcome those people to join the discussion? What exactly
> confuses them? What is their usecase? Will they be satisfied if we add
> the comment pointing that we count _iterations_, not number of bits?
> Again, we count iterations, not the number of set bits. If you are able to
>
On Fri, Dec 11, 2020 at 4:09 PM Yun Levi wrote:
>
> > I didn't understand why is so (I mean "same", I think you rather talking
> > about
> > same order of amount of itterations).
>
> Yes. That's what I want to talk about. Thanks!
>
> > Can you provide before and after to compare?
>
> I tested whe
> I didn't understand why is so (I mean "same", I think you rather talking about
> same order of amount of itterations).
Yes. That's what I want to talk about. Thanks!
> Can you provide before and after to compare?
I tested when the bitmap's 0 bit is set only. and below are before and
after resu
On Fri, Dec 11, 2020 at 12:50 AM Levi Yun wrote:
>
> We should have same iteration count when we walk the same bitmap
> regardless of using find_next_bit or find_last_b
I think it's not that important, because the difference is not measurable.
But if this part raises questions, I have nothing aga
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).
>
We should have same iteration count when we walk the same bitmap
regardless of using find_next_bit or find_last_bit.
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:
6 matches
Mail list logo
