| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAAH8bW_5z8PF4xRtMzG3sNbxAR10rwY=7ftL_E2K-TxzNtnarA@mail.gmail.com>
Date: Fri, 4 Dec 2020 10:14:18 -0800
From: Yury Norov <yury.norov@...il.com>
To: Yun Levi <ppbuk5246@...il.com>
Cc: Willy Tarreau <w@....eu>,
Rasmus Villemoes <linux@...musvillemoes.dk>, dushistov@...l.ru,
Arnd Bergmann <arnd@...db.de>,
Andrew Morton <akpm@...ux-foundation.org>,
"Gustavo A. R. Silva" <gustavo@...eddedor.com>,
William Breathitt Gray <vilhelm.gray@...il.com>,
richard.weiyang@...ux.alibaba.com, joseph.qi@...ux.alibaba.com,
skalluru@...vell.com, Josh Poimboeuf <jpoimboe@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arch@...r.kernel.org,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re:
On Thu, Dec 3, 2020 at 5:36 PM Yun Levi <ppbuk5246@...il.com> wrote:
>
> >On Fri, Dec 4, 2020 at 3:53 AM Willy Tarreau <w@....eu> wrote:
> >
> > On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote:
> > > Yun, could you please stop top-posting and excessive trimming in the thread?
> >
> > And re-configure the mail agent to make the "Subject" field appear and
> > fill it.
>
> >On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote:
> > Yun, could you please stop top-posting and excessive trimming in the thread?
> Sorry to make you uncomfortable... Thanks for advice.
>
> >On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote:
> > As you said, find_last_bit() and proposed find_prev_*_bit() have the
> > same functionality.
> > If you really want to have find_prev_*_bit(), could you please at
> > least write it using find_last_bit(), otherwise it would be just a
> > blottering.
>
> Actually find_prev_*_bit call _find_prev_bit which is a common helper function
> like _find_next_bit.
> As you know this function is required to support __BIGEDIAN's little
> endian search.
> find_prev_bit actually wrapper of _find_prev_bit which have a feature
> the find_last_bit.
>
> That makes the semantics difference between find_last_bit and find_prev_bit.
> -- specify where you find from and
> In loop, find_last_bit couldn't sustain original size as sentinel
> return value
> (we should change the size argument for next searching
> But it means whenever we call, "NOT SET or NOT CLEAR"'s sentinel
> return value is changed per call).
>
> Because we should have _find_prev_bit,
> I think it's the matter to choose which is better to usein
> find_prev_bit (find_last_bit? or _find_prev_bit?)
> sustaining find_prev_bit feature (give size as sentinel return, from
> where I start).
> if my understanding is correct.
>
> In my view, I prefer to use _find_prev_bit like find_next_bit for
> integrated format.
>
> But In some of the benchmarking, find_last_bit is better than _find_prev_bit,
> here what I tested (look similar but sometimes have some difference).
>
> Start testing find_bit() with random-filled bitmap
> [ +0.001850] find_next_bit: 842792 ns, 163788 iterations
> [ +0.000873] find_prev_bit: 870914 ns, 163788 iterations
> [ +0.000824] find_next_zero_bit: 821959 ns, 163894 iterations
> [ +0.000677] find_prev_zero_bit: 676240 ns, 163894 iterations
> [ +0.000777] find_last_bit: 659103 ns, 163788 iterations
> [ +0.001822] find_first_bit: 1708041 ns, 16250 iterations
> [ +0.000539] find_next_and_bit: 492182 ns, 73871 iterations
> [ +0.000001]
> Start testing find_bit() with sparse bitmap
> [ +0.000222] find_next_bit: 13227 ns, 654 iterations
> [ +0.000013] find_prev_bit: 11652 ns, 654 iterations
> [ +0.001845] find_next_zero_bit: 1723869 ns, 327028 iterations
> [ +0.001538] find_prev_zero_bit: 1355808 ns, 327028 iterations
> [ +0.000010] find_last_bit: 8114 ns, 654 iterations
> [ +0.000867] find_first_bit: 710639 ns, 654 iterations
> [ +0.000006] find_next_and_bit: 4273 ns, 1 iterations
> [ +0.000004] find_next_and_bit: 3278 ns, 1 iterations
>
> Start testing find_bit() with random-filled bitmap
> [ +0.001784] find_next_bit: 805553 ns, 164240 iterations
> [ +0.000643] find_prev_bit: 632474 ns, 164240 iterations
> [ +0.000950] find_next_zero_bit: 877215 ns, 163442 iterations
> [ +0.000664] find_prev_zero_bit: 662339 ns, 163442 iterations
> [ +0.000680] find_last_bit: 602204 ns, 164240 iterations
> [ +0.001912] find_first_bit: 1758208 ns, 16408 iterations
> [ +0.000760] find_next_and_bit: 531033 ns, 73798 iterations
> [ +0.000002]
> Start testing find_bit() with sparse bitmap
> [ +0.000203] find_next_bit: 12468 ns, 656 iterations
> [ +0.000205] find_prev_bit: 10948 ns, 656 iterations
> [ +0.001759] find_next_zero_bit: 1579447 ns, 327026 iterations
> [ +0.001935] find_prev_zero_bit: 1931961 ns, 327026 iterations
> [ +0.000013] find_last_bit: 9543 ns, 656 iterations
> [ +0.000732] find_first_bit: 562009 ns, 656 iterations
> [ +0.000217] find_next_and_bit: 6804 ns, 1 iterations
> [ +0.000007] find_next_and_bit: 4367 ns, 1 iterations
>
> Is it better to write find_prev_bit using find_last_bit?
> I question again.
I answer again. It's better not to write find_prev_bit at all and
learn how to use existing functionality.
Yury
> Thanks for your great advice, But please forgive my fault and lackness.
>
> HTH.
> Levi.
Powered by blists - more mailing lists