The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Yi Sun <yi.sun@unisoc.com>
Cc: yury.norov@gmail.com, mina86@mina86.com, 279644543@qq.com,
	mnazarewicz@gmail.com, akpm@linux-foundation.org,
	akinobu.mita@gmail.com, linux-kernel@vger.kernel.org,
	john.stultz@linaro.org, tjmercier@google.com,
	qiang.zhao@freescale.com, scottwood@freescale.com,
	benjamin.gaignard@linaro.org, fvdl@google.com, tglx@kernel.org,
	andreas.herrmann@calxeda.com, song@kernel.org, hch@lst.de,
	sasha.levin@oracle.com, minchan@kernel.org
Subject: Re: [PATCH v5 2/2] lib: bitmap: optimize bitmap_find_next_zero_area_off()
Date: Thu, 18 Jun 2026 02:14:58 -0400	[thread overview]
Message-ID: <ajOM4gs4xsPl_WoM@yury> (raw)
In-Reply-To: <20260618015252.3601554-3-yi.sun@unisoc.com>

On Thu, Jun 18, 2026 at 09:52:52AM +0800, Yi Sun wrote:
> Finding a contiguous free region in a highly fragmented
> bitmap is not easy and may require many repeated attempts.
> Therefore, find_next_bit(map, end, index) is not the optimal choice.
> This is because there may be multiple scattered free regions
> within the range [index, end) and none of them will meet the length
> requirement of @nr.
> Instead, it's sufficient to directly find the last bit within
> the range [index, end), thus reducing unnecessary repeated calls.
> 
> An example of a bitmap:
> Bits 0-3:   cleared(4 bits)
> Bits 4-5:   set    (2 bits)
> Bits 6-8:   cleared(4 bits)
> Bits 9-10:  set    (2 bits)
> Bits 11-20: cleared(10 bits)
> 
> The goal is to find a 10-bit free region.
> 
> The old code logic is as follows:
> find_next_zero_bit(start = 0, find bit 0) -> find_next_bit(find bit 4) ->
> goto again ->
> find_next_zero_bit(start = 5, find bit 6) -> find_next_bit(find bit 9) ->
> goto again ->
> find_next_zero_bit(start = 10, find bit 11) -> success
> 
> The new code logic is as follows:
> find_next_zero_bit(start = 0, find bit 0) -> find_last_bit(find bit 9) ->
> goto again ->
> find_next_zero_bit(start = 10, find bit 11) -> success

In new logic there's no goto, right?

> Performance test results on my hardware(use lib/find_bit_benchmark.c):
> 
> 		before	after	change	p-value
> dense		1211	688	-43.2%	8.3e-11
> sparse		13.3	13.4	0.8%	0.27
> 
> Signed-off-by: Yi Sun <yi.sun@unisoc.com>
> ---
>  lib/bitmap.c | 35 +++++++++++++++++++++--------------
>  1 file changed, 21 insertions(+), 14 deletions(-)
> 
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index b9bfa157e095..a2c4bd22d875 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -432,22 +432,29 @@ unsigned long bitmap_find_next_zero_area_off(unsigned long *map,
>  					     unsigned long align_mask,
>  					     unsigned long align_offset)
>  {
> -	unsigned long index, end, i;
> -again:
> -	index = find_next_zero_bit(map, size, start);
> -
> -	/* Align allocation */
> -	index = __ALIGN_MASK(index + align_offset, align_mask) - align_offset;
> -
> -	end = index + nr;
> -	if (end > size)
> -		return end;
> -	i = find_next_bit(map, end, index);
> -	if (i < end) {
> +	unsigned long find_idx, end, i, find_word_idx, find_word_off;
> +
> +	for (;;) {

"Infinite" loop is nothing better than the backward goto. 
Can you try this:

        unsigned long end, i, off;

        for_each_clear_bit_from(start, map, size) {
                start = __ALIGN_MASK(start + align_offset, align_mask) - align_offset;
                end = start + nr;
                if (end > size)
                        break;

                off = round_down(start, BITS_PER_LONG);
                i = find_last_bit(map + start / BITS_PER_LONG, end - off) + off;
                if (i >= end || i < start)
                        return start;

                start = i;
        }

        return size;

If it works for you, let's move with the for_each() version.
Can you test and add my Co-developed-by please?

Thanks,
Yury

> +		find_idx = find_next_zero_bit(map, size, start);
> +
> +		/* Align allocation */
> +		find_idx = __ALIGN_MASK(find_idx + align_offset,
> +			align_mask) - align_offset;
> +
> +		end = find_idx + nr;
> +		if (end > size)
> +			return end;
> +
> +		find_word_idx = find_idx / BITS_PER_LONG;
> +		find_word_off = find_word_idx * BITS_PER_LONG;
> +
> +		i = find_last_bit(map + find_word_idx,
> +			end - find_word_off) + find_word_off;
> +		if (i >= end || i < find_idx)
> +			return find_idx;
> +
>  		start = i + 1;
> -		goto again;
>  	}
> -	return index;
>  }
>  EXPORT_SYMBOL(bitmap_find_next_zero_area_off);
>  
> -- 
> 2.34.1

  reply	other threads:[~2026-06-18  6:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18  1:52 [PATCH v5 0/2] Improve the performance of bitmap_find_next_zero_area_off() Yi Sun
2026-06-18  1:52 ` [PATCH v5 1/2] lib: bitmap: add tests for bitmap_find_next_zero_area_off() Yi Sun
2026-06-18  5:48   ` Yury Norov
2026-06-18  9:43     ` 答复: " 孙毅 (Yi Sun)
2026-06-18 12:44     ` 孙毅 (Yi Sun)
2026-06-18  1:52 ` [PATCH v5 2/2] lib: bitmap: optimize bitmap_find_next_zero_area_off() Yi Sun
2026-06-18  6:14   ` Yury Norov [this message]
2026-06-18  9:29     ` 答复: " 孙毅 (Yi Sun)

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=ajOM4gs4xsPl_WoM@yury \
    --to=yury.norov@gmail.com \
    --cc=279644543@qq.com \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreas.herrmann@calxeda.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=fvdl@google.com \
    --cc=hch@lst.de \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mina86@mina86.com \
    --cc=minchan@kernel.org \
    --cc=mnazarewicz@gmail.com \
    --cc=qiang.zhao@freescale.com \
    --cc=sasha.levin@oracle.com \
    --cc=scottwood@freescale.com \
    --cc=song@kernel.org \
    --cc=tglx@kernel.org \
    --cc=tjmercier@google.com \
    --cc=yi.sun@unisoc.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