All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Yury Norov <yury.norov@gmail.com>, linux-kernel@vger.kernel.org
Cc: linux-m68k@lists.linux-m68k.org, linux-arch@vger.kernel.org,
	linux-sh@vger.kernel.org, Alexey Klimov <aklimov@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Arnd Bergmann <arnd@arndb.de>, David Sterba <dsterba@suse.com>,
	Dennis Zhou <dennis@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Jianpeng Ma <jianpeng.ma@intel.com>,
	Joe Perches <joe@perches.com>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Rich Felker <dalias@libc.org>,
	Stefano Brivio <sbrivio@redhat.com>,
	Wei Yang <richard.weiyang@linux.alibaba.com>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>
Subject: Re: [PATCH 06/13] lib: extend the scope of small_const_nbits() macro
Date: Tue, 16 Mar 2021 09:56:49 +0100	[thread overview]
Message-ID: <e89b04d4-c2d5-1999-ed72-45bdc03a7bab@rasmusvillemoes.dk> (raw)
In-Reply-To: <20210316015424.1999082-7-yury.norov@gmail.com>

On 16/03/2021 02.54, Yury Norov wrote:
> find_bit would also benefit from small_const_nbits() optimizations.
> 
> Signed-off-by: Yury Norov <yury.norov@gmail.com>
> ---
>  include/asm-generic/bitsperlong.h | 9 +++++++++
>  include/linux/bitmap.h            | 3 ---
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/include/asm-generic/bitsperlong.h b/include/asm-generic/bitsperlong.h
> index 3905c1c93dc2..96032f4f908f 100644
> --- a/include/asm-generic/bitsperlong.h
> +++ b/include/asm-generic/bitsperlong.h
> @@ -23,4 +23,13 @@
>  #define BITS_PER_LONG_LONG 64
>  #endif
>  
> +#define SMALL_CONST(n) (__builtin_constant_p(n) && (unsigned long)(n) < BITS_PER_LONG)
> +
> +/*
> + * The valid number of bits for a bitmap to be small enough, or in other words,
> + * fit into a single machine word is 1 to BITS_PER_LONG inclusively. 0 is not a
> + * valid number for size, and most probably a sing of error.
> + */
> +#define small_const_nbits(n) SMALL_CONST((n) - 1)
> +

I still don't see the point of introducing SMALL_CONST and still don't
like the much-too-generic-name - especially since AFAICT you don't
actually use it anywhere outside the definition of small_const_nbits()?

>  #endif /* __ASM_GENERIC_BITS_PER_LONG */
> diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
> index adf7bd9f0467..bc13a890ecc1 100644
> --- a/include/linux/bitmap.h
> +++ b/include/linux/bitmap.h
> @@ -224,9 +224,6 @@ extern int bitmap_print_to_pagebuf(bool list, char *buf,
>   * so make such users (should any ever turn up) call the out-of-line
>   * versions.
>   */

You added another comment near its new definition, but the left-behind
comment in bitmap.h is now somewhat confusing, no? I suggest expanding
your new comment a bit so it's clear why we're interested in whether a
bitmap is known at compile-time to consist of exactly one word:

/*
small_const_nbits(n) is true precisely when it is known at compile-time
that BITMAP_SIZE(n) is 1, i.e. 1 <= n <= BITS_PER_LONG. This allows
various bit/bitmap APIs to provide a fast inline implementation. Bitmaps
of size 0 are very rare, and a compile-time-known-size 0 is most likely
a sign of error. They will be handled correctly by the bit/bitmap APIs,
but using the out-of-line functions, so that the inline implementations
can unconditionally dereference the pointer(s).
*/

> -#define small_const_nbits(nbits) \
> -	(__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG && (nbits) > 0)
> -
>  static inline void bitmap_zero(unsigned long *dst, unsigned int nbits)
>  {
>  	unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
> 

Rasmus

  reply	other threads:[~2021-03-16  8:57 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16  1:54 [PATCH v4 00/13] lib/find_bit: fast path for small bitmaps Yury Norov
2021-03-16  1:54 ` [PATCH 01/13] tools: disable -Wno-type-limits Yury Norov
2021-03-16  8:17   ` Rasmus Villemoes
2021-03-16 11:39     ` Andy Shevchenko
2021-03-16  1:54 ` [PATCH 02/13] tools: bitmap: sync function declarations with the kernel Yury Norov
2021-03-16  8:18   ` Rasmus Villemoes
2021-03-16  1:54 ` [PATCH 03/13] arch: rearrange headers inclusion order in asm/bitops for m68k and sh Yury Norov
2021-03-16  1:54 ` [PATCH 04/13] lib: introduce BITS_{FIRST,LAST} macro Yury Norov
2021-03-16  8:35   ` Rasmus Villemoes
2021-03-16 11:42     ` Andy Shevchenko
2021-03-17  5:40       ` Yury Norov
2021-03-17 19:58         ` Rasmus Villemoes
2021-03-17 23:33           ` Yury Norov
2021-03-16  1:54 ` [PATCH 05/13] tools: sync BITS_MASK macros with the kernel Yury Norov
2021-03-16  1:54 ` [PATCH 06/13] lib: extend the scope of small_const_nbits() macro Yury Norov
2021-03-16  8:56   ` Rasmus Villemoes [this message]
2021-03-17  4:53     ` Yury Norov
2021-03-16  1:54 ` [PATCH 07/13] tools: sync small_const_nbits() macro with the kernel Yury Norov
2021-03-16  1:54 ` [PATCH 08/13] lib: inline _find_next_bit() wrappers Yury Norov
2021-03-16  1:54 ` [PATCH 09/13] tools: sync find_next_bit implementation Yury Norov
2021-03-16  1:54 ` [PATCH 10/13] lib: add fast path for find_next_*_bit() Yury Norov
2021-03-16  1:54 ` [PATCH 11/13] lib: add fast path for find_first_*_bit() and find_last_bit() Yury Norov
2021-04-06 16:03   ` Guenter Roeck
2021-04-06 18:15     ` Yury Norov
2021-03-16  1:54 ` [PATCH 12/13] tools: sync lib/find_bit implementation Yury Norov
2021-03-16  1:54 ` [PATCH 13/13] MAINTAINERS: Add entry for the bitmap API Yury Norov
2021-03-16 11:45   ` Andy Shevchenko
2021-03-17  4:47     ` Yury Norov
2021-03-17  4:57       ` Joe Perches
2021-03-17  6:40         ` Lukas Bulwahn
2021-03-17 19:29           ` Yury Norov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e89b04d4-c2d5-1999-ed72-45bdc03a7bab@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=aklimov@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=dalias@libc.org \
    --cc=dennis@kernel.org \
    --cc=dsterba@suse.com \
    --cc=geert@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=jianpeng.ma@intel.com \
    --cc=joe@perches.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=richard.weiyang@linux.alibaba.com \
    --cc=sbrivio@redhat.com \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=ysato@users.sourceforge.jp \
    --cc=yury.norov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.