From: "Alexander van Heukelum" <heukelum@fastmail.fm>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
"Alexander van Heukelum" <heukelum@mailshack.com>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
"LKML" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: Change x86 to use generic find_next_bit
Date: Thu, 13 Mar 2008 15:27:59 +0100 [thread overview]
Message-ID: <1205418479.9375.1242203645@webmail.messagingengine.com> (raw)
In-Reply-To: <20080313124424.GA18774@skywalker>
On Thu, 13 Mar 2008 18:14:24 +0530, "Aneesh Kumar K.V"
<aneesh.kumar@linux.vnet.ibm.com> said:
> On Sun, Mar 09, 2008 at 09:01:04PM +0100, Alexander van Heukelum wrote:
> > x86: Change x86 to use the generic find_next_bit implementation
> >
> > The versions with inline assembly are in fact slower on the machines I
> > tested them on (in userspace) (Athlon XP 2800+, p4-like Xeon 2.8GHz, AMD
> > Opteron 270). The i386-version needed a fix similar to 06024f21 to avoid
> > crashing the benchmark.
> >
> > Benchmark using: gcc -fomit-frame-pointer -Os. For each bitmap size
> > 1...512, for each possible bitmap with one bit set, for each possible
> > offset: find the position of the first bit starting at offset. If you
> > follow ;). Times include setup of the bitmap and checking of the
> > results.
> >
> > Athlon Xeon Opteron 32/64bit
> > x86-specific: 0m3.692s 0m2.820s 0m3.196s / 0m2.480s
> > generic: 0m2.622s 0m1.662s 0m2.100s / 0m1.572s
> >
> > If the bitmap size is not a multiple of BITS_PER_LONG, and no set
> > (cleared) bit is found, find_next_bit (find_next_zero_bit) returns a
> > value outside of the range [0,size]. The generic version always returns
> > exactly size. The generic version also uses unsigned long everywhere,
> > while the x86 versions use a mishmash of int, unsigned (int), long and
> > unsigned long.
>
> This problem is observed on x86_64 and powerpc also.
I'm not entirely sure if it is a problem. In some cases it
certainly is an inconvenience, though ;). I mentioned the
difference between the old and generic versions, because
of the possibility of dependence of this behaviour.
Indeed I see for example (in fs/ext4/mballoc.c).
bit = mb_find_next_zero_bit(bitmap_bh->b_data, end, bit);
if (bit >= end)
break;
next = mb_find_next_bit(bitmap_bh->b_data, end, bit);
if (next > end)
next = end;
free += next - bit;
So here it needed to adjust the value.
> We need a long
> aligned address for test_bit, set_bit find_bit etc. In ext4 we have
> to make sure we align the address passed to
>
> ext4_test_bit
> ext4_set_bit
> ext4_find_next_zero_bit
> ext4_find_next_bit
>
> fs/ext4/mballoc.c have some examples.
This is a different 'problem'. find_next_bit works on arrays of long,
while the bitmaps in ext4_find_next_bit are of type void * and seem
not to have any alignment restrictions. ext4 implements wrappers
around find_next_bit to solve that 'problem'.
The question that arises is: do we want find_first_bit, find_next_bit.
etc. to always return a value in the range [0, size], or do we want
to allow implementations that return [0, size-1] if there is a bit
found and something else (roundup(size,bitsperlong) or ulongmax, for
example if, none were found?
The current x86_64 versions of find_first_bit and find_next_bit return
roundup(size,bitsperlong) if no bits were found, but on the other hand
I guess most bitmaps are a multiple of bitsperlong bits in size, which
hides the difference.
Greetings,
Alexander
> -aneesh
--
Alexander van Heukelum
heukelum@fastmail.fm
--
http://www.fastmail.fm - Or how I learned to stop worrying and
love email again
prev parent reply other threads:[~2008-03-13 14:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-09 20:01 [PATCH] x86: Change x86 to use generic find_next_bit Alexander van Heukelum
2008-03-09 20:10 ` Ingo Molnar
2008-03-09 21:03 ` Andi Kleen
2008-03-09 21:32 ` Andi Kleen
2008-03-09 21:13 ` Alexander van Heukelum
2008-03-10 6:29 ` Ingo Molnar
2008-03-09 20:11 ` Ingo Molnar
2008-03-09 20:31 ` Alexander van Heukelum
2008-03-09 20:51 ` Ingo Molnar
2008-03-09 21:29 ` Andi Kleen
2008-03-10 23:17 ` [RFC/PATCH] x86: Optimize find_next_(zero_)bit for small constant-size bitmaps Alexander van Heukelum
2008-03-11 9:56 ` Ingo Molnar
2008-03-11 15:17 ` [PATCH] " Alexander van Heukelum
2008-03-11 15:22 ` [RFC] non-x86: " Alexander van Heukelum
2008-03-11 15:23 ` [PATCH] x86: " Ingo Molnar
2008-03-09 20:28 ` [PATCH] x86: Change x86 to use generic find_next_bit Andi Kleen
2008-03-09 21:31 ` Andi Kleen
2008-03-13 12:44 ` Aneesh Kumar K.V
2008-03-13 14:27 ` Alexander van Heukelum [this message]
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=1205418479.9375.1242203645@webmail.messagingengine.com \
--to=heukelum@fastmail.fm \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=heukelum@mailshack.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).