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 2/2] lib: bitmap: reduce the number of goto again in bitmap_find_next_zero_area_off()
Date: Thu, 14 May 2026 13:18:40 -0400 [thread overview]
Message-ID: <agYD8Iu5WD6ACOMq@yury> (raw)
In-Reply-To: <20260514090607.231387-3-yi.sun@unisoc.com>
On Thu, May 14, 2026 at 05:06:07PM +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 "goto again" calls.
This is the good place to put your perf numbers. Does it have a real
impact, other than the micro-benchmark?
> Signed-off-by: Yi Sun <yi.sun@unisoc.com>
There is a for_each_set_bit_range() iterators family. They are similar
to the bitmap_find_next_zero_area_off(), and may also benefit from the
rework.
I think the most questionable part of this work is that you switch a
single function to the new API. Can you check the above and other
possible candidates please, before we move forward?
Thanks,
Yury
> ---
> lib/bitmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index b9bfa157e095..9b589643f72a 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -442,7 +442,7 @@ unsigned long bitmap_find_next_zero_area_off(unsigned long *map,
> end = index + nr;
> if (end > size)
> return end;
> - i = find_next_bit(map, end, index);
> + i = find_last_bit_from(map, end, index);
> if (i < end) {
> start = i + 1;
> goto again;
> --
> 2.34.1
next prev parent reply other threads:[~2026-05-14 17:18 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
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 [this message]
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=agYD8Iu5WD6ACOMq@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 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.