The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Yury Norov <ynorov@nvidia.com>
To: Yi Sun <yi.sun@unisoc.com>
Cc: yury.norov@gmail.com, mnazarewicz@gmail.com,
	akpm@linux-foundation.org, mina86@mina86.com,
	akinobu.mita@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] lib: bitmap: add find_last_bit_from() and _find_last_bit_from()
Date: Thu, 14 May 2026 12:49:28 -0400	[thread overview]
Message-ID: <agX9GEDR_CP-3WMk@yury> (raw)
In-Reply-To: <20260514090607.231387-2-yi.sun@unisoc.com>

On Thu, May 14, 2026 at 05:06:06PM +0800, Yi Sun wrote:
> In some scenarios, it's not desirable to keep searching through the
> beginning of the bitmap, but rather to search within a specific part.
> The newly added function can accomplish this quickly.
> 
> Signed-off-by: Yi Sun <yi.sun@unisoc.com>

On the previous round you said:

  find_last_bit_range() is only used here for now, but I believe it will be useful in the future.

And didn't let me answer by outdating that discussion with two new
versions. Please don't do like that.

So my answer to the sentence above is: unless that bright future comes
true, the find_last_bit_range() is unused, except for one in-house
case. This makes it questionable if we really need the new exposed API
at all...

There are 63 references of the find_last_bit(). Please inspect them all.
If there will be another user, this question will be out of the table.

> ---
>  include/linux/find.h | 33 +++++++++++++++++++++++++++++++++
>  lib/find_bit.c       | 22 ++++++++++++++++++++++
>  2 files changed, 55 insertions(+)
> 
> diff --git a/include/linux/find.h b/include/linux/find.h
> index 6c2be8ca615d..17f1db7b41fb 100644
> --- a/include/linux/find.h
> +++ b/include/linux/find.h
> @@ -33,6 +33,8 @@ unsigned long _find_first_and_and_bit(const unsigned long *addr1, const unsigned
>  				      const unsigned long *addr3, unsigned long size);
>  extern unsigned long _find_first_zero_bit(const unsigned long *addr, unsigned long size);
>  extern unsigned long _find_last_bit(const unsigned long *addr, unsigned long size);
> +extern unsigned long _find_last_bit_from(const unsigned long *addr, unsigned long size,
> +					unsigned long offset);
>  
>  #ifdef __BIG_ENDIAN
>  unsigned long _find_first_zero_bit_le(const unsigned long *addr, unsigned long size);
> @@ -413,6 +415,37 @@ unsigned long find_last_bit(const unsigned long *addr, unsigned long size)
>  }
>  #endif
>  
> +/**
> + * find_last_bit_from - find the last set bit in a memory region
> + * @addr: The address to base the search on
> + * @size: The bitmap size in bits
> + * @offset: The bit number to start searching at
> + *
> + * Compared to the find_last_bit(),
> + * find_last_bit_from() has an additional parameter @offset,
> + * so it can search within a specific range of the bitmap,
> + * just like the find_next_bit().
> + *
> + * Returns the bit number of the last set bit, or size.
> + */
> +static __always_inline
> +unsigned long find_last_bit_from(const unsigned long *addr, unsigned long size,
> +				unsigned long offset)
> +{
> +	if (small_const_nbits(size)) {
> +		unsigned long val;
> +
> +		if (unlikely(offset >= size))
> +			return size;
> +
> +		val = *addr & GENMASK(size - 1, offset);
> +
> +		return val ? __fls(val) : size;
> +	}
> +
> +	return _find_last_bit_from(addr, size, offset);
> +}

On the previous round I suggested the implementation based on
find_last_bit(), so that you don't need to create an outline
_find_last_bit_from() function and expose it. Can you compare the
implementations for the performance impact. If they are on par,
I'd stick to one re-using the existing code.

Thanks,
Yury

> +
>  /**
>   * find_next_and_bit_wrap - find the next set bit in both memory regions
>   * @addr1: The first address to base the search on
> diff --git a/lib/find_bit.c b/lib/find_bit.c
> index 5ac52dfce730..196b946dafff 100644
> --- a/lib/find_bit.c
> +++ b/lib/find_bit.c
> @@ -237,6 +237,28 @@ unsigned long _find_last_bit(const unsigned long *addr, unsigned long size)
>  EXPORT_SYMBOL(_find_last_bit);
>  #endif
>  
> +unsigned long _find_last_bit_from(const unsigned long *addr, unsigned long size,
> +				unsigned long offset)
> +{
> +	unsigned long val, idx, start_idx;
> +
> +	if (unlikely(offset >= size))
> +		return size;
> +
> +	start_idx = offset / BITS_PER_LONG;
> +	idx = (size - 1) / BITS_PER_LONG;
> +	val = addr[idx] & BITMAP_LAST_WORD_MASK(size);
> +
> +	while (!val && idx > start_idx)
> +		val = addr[--idx];
> +
> +	if (idx == start_idx)
> +		val &= BITMAP_FIRST_WORD_MASK(offset);
> +
> +	return val ? idx * BITS_PER_LONG + __fls(val) : size;
> +}
> +EXPORT_SYMBOL(_find_last_bit_from);
> +
>  unsigned long find_next_clump8(unsigned long *clump, const unsigned long *addr,
>  			       unsigned long size, unsigned long offset)
>  {
> -- 
> 2.34.1

  parent reply	other threads:[~2026-05-14 16:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14  9:06 [PATCH v3 0/2] Improve the performance of bitmap_find_next_zero_area_off() Yi Sun
2026-05-14  9:06 ` [PATCH v3 1/2] lib: bitmap: add find_last_bit_from() and _find_last_bit_from() Yi Sun
2026-05-14 10:51   ` Michał Nazarewicz
2026-05-14 16:49   ` Yury Norov [this message]
2026-05-14  9:06 ` [PATCH v3 2/2] lib: bitmap: reduce the number of goto again in bitmap_find_next_zero_area_off() Yi Sun
2026-05-14 10:51   ` Michał Nazarewicz
2026-05-14 17:18   ` Yury Norov
2026-05-14 15:54 ` [PATCH v3 0/2] Improve the performance of bitmap_find_next_zero_area_off() 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=agX9GEDR_CP-3WMk@yury \
    --to=ynorov@nvidia.com \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mina86@mina86.com \
    --cc=mnazarewicz@gmail.com \
    --cc=yi.sun@unisoc.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox