* [PATCH v2] bitmap: speedup in bitmap_find_free_region when order is 0
@ 2013-04-09 2:44 Chanho Min
2013-04-09 3:10 ` Andrew Morton
0 siblings, 1 reply; 6+ messages in thread
From: Chanho Min @ 2013-04-09 2:44 UTC (permalink / raw)
To: Andrew Morton, Nadia Yvette Chambers, Jiri Kosina,
Guennadi Liakhovetski
Cc: linux-kernel, Chanho Min
If bitmap_find_free_region() is called with order=0, We can reduce
for-loops to find 1 free bit. First, It scans bitmap array by the
increment of long type, then find 1 free bit within 1 long type value.
In 32 bits system and 1024 bits size, in the worst case, We need 1024
for-loops to find 1 free bit. But, If This is applied, it takes
64 for-loops. Instead, if free bit is in the first index of the bitmaps,
It will be needed additional 1 for-loop. But from second index, It
will speed up significantly.
Changes compared to v1:
- Modified unnecessarily complicated code.
- Fixed the buggy code if `bits' is not an multiple of BITS_PER_LONG.
Signed-off-by: Chanho Min <chanho.min@lge.com>
---
lib/bitmap.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 06f7e4f..663fc28 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -1099,6 +1099,39 @@ done:
}
/**
+ * bitmap_find_free_one - find a mem region
+ * @bitmap: array of unsigned longs corresponding to the bitmap
+ * @bits: number of bits in the bitmap
+ *
+ * Find one of free (zero) bits in a @bitmap of @bits bits and
+ * allocate them (set them to one).
+ *
+ * Return the bit offset in bitmap of the allocated region,
+ * or -errno on failure.
+ */
+static int __bitmap_find_free_one(unsigned long *bitmap, int bits)
+{
+ int pos, end = BITS_PER_LONG, i;
+ int nlongs_reg = BITS_TO_LONGS(bits);
+ int last_bits = bits % BITS_PER_LONG;
+
+ for (i = 0 ; i < nlongs_reg ; i++) {
+ if (bitmap[i] != ~0UL) {
+ if (i == (nlongs_reg - 1) && last_bits)
+ end = last_bits;
+ for (pos = 0 ; pos < end ; pos++) {
+ if (!__reg_op(&bitmap[i], pos, 0,
+ REG_OP_ISFREE))
+ continue;
+ __reg_op(&bitmap[i], pos, 0, REG_OP_ALLOC);
+ return pos;
+ }
+ }
+ }
+ return -ENOMEM;
+}
+
+/**
* bitmap_find_free_region - find a contiguous aligned mem region
* @bitmap: array of unsigned longs corresponding to the bitmap
* @bits: number of bits in the bitmap
@@ -1116,6 +1149,9 @@ int bitmap_find_free_region(unsigned long *bitmap, int bits, int order)
{
int pos, end; /* scans bitmap by regions of size order */
+ if (order == 0)
+ return __bitmap_find_free_one(bitmap, bits);
+
for (pos = 0 ; (end = pos + (1 << order)) <= bits; pos = end) {
if (!__reg_op(bitmap, pos, order, REG_OP_ISFREE))
continue;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] bitmap: speedup in bitmap_find_free_region when order is 0
2013-04-09 2:44 [PATCH v2] bitmap: speedup in bitmap_find_free_region when order is 0 Chanho Min
@ 2013-04-09 3:10 ` Andrew Morton
2013-04-09 3:18 ` Joe Perches
[not found] ` <5163b689.64d3440a.731b.ffff9984SMTPIN_ADDED_BROKEN@mx.google.com>
0 siblings, 2 replies; 6+ messages in thread
From: Andrew Morton @ 2013-04-09 3:10 UTC (permalink / raw)
To: Chanho Min
Cc: Nadia Yvette Chambers, Jiri Kosina, Guennadi Liakhovetski,
linux-kernel
On Tue, 9 Apr 2013 11:44:46 +0900 Chanho Min <chanho.min@lge.com> wrote:
> If bitmap_find_free_region() is called with order=0, We can reduce
> for-loops to find 1 free bit. First, It scans bitmap array by the
> increment of long type, then find 1 free bit within 1 long type value.
>
> In 32 bits system and 1024 bits size, in the worst case, We need 1024
> for-loops to find 1 free bit. But, If This is applied, it takes
> 64 for-loops. Instead, if free bit is in the first index of the bitmaps,
> It will be needed additional 1 for-loop. But from second index, It
> will speed up significantly.
>
> Changes compared to v1:
> - Modified unnecessarily complicated code.
> - Fixed the buggy code if `bits' is not an multiple of BITS_PER_LONG.
>
> ...
>
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -1099,6 +1099,39 @@ done:
> }
>
> /**
> + * bitmap_find_free_one - find a mem region
> + * @bitmap: array of unsigned longs corresponding to the bitmap
> + * @bits: number of bits in the bitmap
> + *
> + * Find one of free (zero) bits in a @bitmap of @bits bits and
> + * allocate them (set them to one).
> + *
> + * Return the bit offset in bitmap of the allocated region,
> + * or -errno on failure.
> + */
> +static int __bitmap_find_free_one(unsigned long *bitmap, int bits)
> +{
> + int pos, end = BITS_PER_LONG, i;
> + int nlongs_reg = BITS_TO_LONGS(bits);
Still wrong, I think - BITS_TO_LONG() rounds up.
> + int last_bits = bits % BITS_PER_LONG;
> +
> + for (i = 0 ; i < nlongs_reg ; i++) {
No space before the semicolon, please. checkpatch should warn about
this but it seems to be broken.
> + if (bitmap[i] != ~0UL) {
> + if (i == (nlongs_reg - 1) && last_bits)
> + end = last_bits;
> + for (pos = 0 ; pos < end ; pos++) {
> + if (!__reg_op(&bitmap[i], pos, 0,
> + REG_OP_ISFREE))
> + continue;
> + __reg_op(&bitmap[i], pos, 0, REG_OP_ALLOC);
> + return pos;
> + }
> + }
> + }
> + return -ENOMEM;
> +}
> +
> +/**
> * bitmap_find_free_region - find a contiguous aligned mem region
> * @bitmap: array of unsigned longs corresponding to the bitmap
> * @bits: number of bits in the bitmap
> @@ -1116,6 +1149,9 @@ int bitmap_find_free_region(unsigned long *bitmap, int bits, int order)
> {
> int pos, end; /* scans bitmap by regions of size order */
>
> + if (order == 0)
> + return __bitmap_find_free_one(bitmap, bits);
> +
> for (pos = 0 ; (end = pos + (1 << order)) <= bits; pos = end) {
> if (!__reg_op(bitmap, pos, order, REG_OP_ISFREE))
> continue;
It seems excessively complicated to me. Why not change
bitmap_find_free_region() to skip the leading all-ones words and when
it finds a not-all-ones word, adjust `pos' then fall into the existing
bit-at-a-time search?
In fact we could use the 64-bits-at-a-time search for allocations other
than order-zero:
--- a/lib/bitmap.c~a
+++ a/lib/bitmap.c
@@ -1117,6 +1117,12 @@ int bitmap_find_free_region(unsigned lon
int pos, end; /* scans bitmap by regions of size order */
for (pos = 0 ; (end = pos + (1 << order)) <= bits; pos = end) {
+ if (pos & (BITS_PER_LONG - 1) == 0) {
+ if (bitmap[pos / BITS_PER_LONG] == ~0UL) {
+ pos += BITS_PER_LONG;
+ continue;
+ }
+ }
if (!__reg_op(bitmap, pos, order, REG_OP_ISFREE))
continue;
__reg_op(bitmap, pos, order, REG_OP_ALLOC);
(that's presumably slow and buggy, but you get the idea ;))
Another obvious inefficiency in bitmap_find_free_region() is that when
it inspects a region at `pos' for 1<<order zero bits and fails to find
them, it resumes the search at pos+1. Dumb - it should resume
searching at the next-one-bit, rounded up to the next 1<<order.
Obviously nobody tried very hard here - is any poor soul using this
code for large bitmaps? I guess "yes", as 1024-CPU machines exist.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] bitmap: speedup in bitmap_find_free_region when order is 0
2013-04-09 3:10 ` Andrew Morton
@ 2013-04-09 3:18 ` Joe Perches
2013-04-09 4:18 ` Andrew Morton
[not found] ` <5163b689.64d3440a.731b.ffff9984SMTPIN_ADDED_BROKEN@mx.google.com>
1 sibling, 1 reply; 6+ messages in thread
From: Joe Perches @ 2013-04-09 3:18 UTC (permalink / raw)
To: Andrew Morton
Cc: Chanho Min, Nadia Yvette Chambers, Jiri Kosina,
Guennadi Liakhovetski, linux-kernel
On Mon, 2013-04-08 at 20:10 -0700, Andrew Morton wrote:
> > --- a/lib/bitmap.c
[]
> > + for (i = 0 ; i < nlongs_reg ; i++) {
>
> No space before the semicolon, please. checkpatch should warn about
> this but it seems to be broken.
There's no specific CodingStyle violation here
Adding --strict does bleat though.
# check for whitespace before a non-naked semicolon
if ($line =~ /^\+.*\S\s+;/) {
CHK("SPACING",
"space prohibited before semicolon\n" . $herecurr);
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] bitmap: speedup in bitmap_find_free_region when order is 0
2013-04-09 3:18 ` Joe Perches
@ 2013-04-09 4:18 ` Andrew Morton
2013-04-09 4:27 ` checkpatch: Warn on space before semicolon Joe Perches
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2013-04-09 4:18 UTC (permalink / raw)
To: Joe Perches
Cc: Chanho Min, Nadia Yvette Chambers, Jiri Kosina,
Guennadi Liakhovetski, linux-kernel
On Mon, 08 Apr 2013 20:18:20 -0700 Joe Perches <joe@perches.com> wrote:
> On Mon, 2013-04-08 at 20:10 -0700, Andrew Morton wrote:
> > > --- a/lib/bitmap.c
> []
> > > + for (i = 0 ; i < nlongs_reg ; i++) {
> >
> > No space before the semicolon, please. checkpatch should warn about
> > this but it seems to be broken.
>
> There's no specific CodingStyle violation here
Let's fix CodingStyle then? Nobody puts spaces before semis - perish
the thought! (I count 4,254,057 versus 8,416 in .c)
> Adding --strict does bleat though.
And let's make it default please.
> # check for whitespace before a non-naked semicolon
> if ($line =~ /^\+.*\S\s+;/) {
> CHK("SPACING",
> "space prohibited before semicolon\n" . $herecurr);
> }
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* checkpatch: Warn on space before semicolon
2013-04-09 4:18 ` Andrew Morton
@ 2013-04-09 4:27 ` Joe Perches
0 siblings, 0 replies; 6+ messages in thread
From: Joe Perches @ 2013-04-09 4:27 UTC (permalink / raw)
To: Andrew Morton
Cc: Chanho Min, Nadia Yvette Chambers, Jiri Kosina,
Guennadi Liakhovetski, linux-kernel
Make space before semicolon a warning instead
of a --strict CHK test.
Signed-off-by: Joe Perches <joe@perches.com>
---
>> There's no specific CodingStyle violation here
> Let's fix CodingStyle then?
I'll leave that bit for you...
scripts/checkpatch.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b28cc38..90eb022 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2514,8 +2514,8 @@ sub process {
# check for whitespace before a non-naked semicolon
if ($line =~ /^\+.*\S\s+;/) {
- CHK("SPACING",
- "space prohibited before semicolon\n" . $herecurr);
+ WARN("SPACING",
+ "space prohibited before semicolon\n" . $herecurr);
}
# Check operator spacing.
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] bitmap: speedup in bitmap_find_free_region when order is 0
[not found] ` <5163b689.64d3440a.731b.ffff9984SMTPIN_ADDED_BROKEN@mx.google.com>
@ 2013-04-09 20:22 ` Andrew Morton
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Morton @ 2013-04-09 20:22 UTC (permalink / raw)
To: Chanho Min
Cc: 'Nadia Yvette Chambers', 'Jiri Kosina',
'Guennadi Liakhovetski', linux-kernel
On Tue, 9 Apr 2013 15:34:44 +0900 "Chanho Min" <chanho.min@lge.com> wrote:
> >It seems excessively complicated to me. Why not change
> >bitmap_find_free_region() to skip the leading all-ones words and when
> >it finds a not-all-ones word, adjust `pos' then fall into the existing
> >bit-at-a-time search?
>
> Do we need the additional 'if' inside the for loop for implementing it?
It was just a concept - there are various ways of optimizing a real
implementation. Move the code into userspace then run some
microbenchmarks.
> I thought the separation of the routine for order=0 is the way to avoid
> the impact on the existing codes and its performance.
The existing code doesn't have any performance ;) It's so darn slow
that even a minor effort here will yield large (ie order-of-magnitude)
performance improvements.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-04-09 20:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-09 2:44 [PATCH v2] bitmap: speedup in bitmap_find_free_region when order is 0 Chanho Min
2013-04-09 3:10 ` Andrew Morton
2013-04-09 3:18 ` Joe Perches
2013-04-09 4:18 ` Andrew Morton
2013-04-09 4:27 ` checkpatch: Warn on space before semicolon Joe Perches
[not found] ` <5163b689.64d3440a.731b.ffff9984SMTPIN_ADDED_BROKEN@mx.google.com>
2013-04-09 20:22 ` [PATCH v2] bitmap: speedup in bitmap_find_free_region when order is 0 Andrew Morton
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.