From: Andrew Morton <akpm@linux-foundation.org>
To: Yury Norov <yury.norov@gmail.com>
Cc: linux@horizon.com, klimov.linux@gmail.com,
linux@rasmusvillemoes.dk, davem@davemloft.net,
dborkman@redhat.com, hannes@stressinduktion.org,
laijs@cn.fujitsu.com, msalter@redhat.com,
takahiro.akashi@linaro.org, tgraf@suug.ch,
valentinrothberg@gmail.com, linux-kernel@vger.kernel.org,
chris@chris-wilson.co.uk
Subject: Re: [PATCH v5 0/3] lib: find_*_bit reimplementation
Date: Mon, 23 Feb 2015 16:40:35 -0800 [thread overview]
Message-ID: <20150223164035.65bb0c11bb17b9a3857e713f@linux-foundation.org> (raw)
In-Reply-To: <1424625857-19354-1-git-send-email-yury.norov@gmail.com>
On Sun, 22 Feb 2015 20:24:14 +0300 Yury Norov <yury.norov@gmail.com> wrote:
> This patchset does rework find_bit functions family to achieve better
> performance, and decrease size of text. All rework is done in patch 1.
> Patches 2 and 3 are about code moving and renaming.
>
> It was boot-tested on x86_64 and MIPS (big-endian) machines.
> Performance tests were ran on userspace with code like this:
>
> /* addr[] is filled from /dev/urandom */
> start = clock();
> while (ret < nbits)
> ret = find_next_bit(addr, nbits, ret + 1);
>
> end = clock();
> printf("%ld\t", (unsigned long) end - start);
>
> On Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz measuremets are next:
> (for find_next_bit, nbits is 8M, for find_first_bit - 80K)
>
> find_next_bit: find_first_bit:
> new current new current
> 26932 43151 14777 14925
> 26947 43182 14521 15423
> 26507 43824 15053 14705
> 27329 43759 14473 14777
> 26895 43367 14847 15023
> 26990 43693 15103 15163
> 26775 43299 15067 15232
> 27282 42752 14544 15121
> 27504 43088 14644 14858
> 26761 43856 14699 15193
> 26692 43075 14781 14681
> 27137 42969 14451 15061
> ... ...
>
> find_next_bit performance gain is 35-40%;
> find_first_bit - no measurable difference.
>
> On ARM machine, there is arch-specific implementation for find_bit.
> To disable it, and use generic one, please apply next patch:
I avoid putting patches into changelogs because in some situations
patch(1) tries to apply it when you apply the real patch. Maybe you
can share the userspace test harness with someone who has access to an
arm machine?
Patches 2 and 3 are missing your signed-off-by:. I added it to my
copies of those patches.
next prev parent reply other threads:[~2015-02-24 0:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-08 14:10 [PATCH v3 " Yury Norov
2015-02-08 14:10 ` [PATCH v3 1/3] " Yury Norov
2015-02-08 18:48 ` George Spelvin
2015-02-09 8:32 ` George Spelvin
2015-02-09 11:53 ` Rasmus Villemoes
2015-02-09 16:45 ` George Spelvin
2015-02-11 22:14 ` Rasmus Villemoes
2015-02-11 23:05 ` Yury
2015-02-12 8:15 ` George Spelvin
2015-02-12 9:58 ` Rasmus Villemoes
2015-02-12 23:46 ` George Spelvin
2015-02-13 10:13 ` Rasmus Villemoes
2015-02-08 14:10 ` [PATCH v3 2/3] lib: move find_last_bit to lib/find_next_bit.c Yury Norov
2015-02-08 14:10 ` [PATCH v3 3/3] lib: rename lib/find_next_bit.c to lib/find_bit.c Yury Norov
2015-02-17 2:35 ` [PATCH v4 0/3] lib: find_*_bit reimplementation Yury Norov
2015-02-17 2:35 ` [PATCH v4 1/3] " Yury Norov
2015-02-18 17:57 ` Rasmus Villemoes
2015-02-17 2:35 ` [PATCH v4 2/3] lib: move find_last_bit to lib/find_next_bit.c Yury Norov
2015-02-17 2:35 ` [PATCH v4 3/3] lib: rename lib/find_next_bit.c to lib/find_bit.c Yury Norov
2015-02-22 17:24 ` [PATCH v5 0/3] lib: find_*_bit reimplementation Yury Norov
2015-02-22 17:24 ` [PATCH v5 1/3] " Yury Norov
2015-02-23 21:50 ` Rasmus Villemoes
2015-02-24 0:29 ` George Spelvin
2015-02-22 17:24 ` [PATCH v5 2/3] lib: move find_last_bit to lib/find_next_bit.c Yury Norov
2015-02-22 17:24 ` [PATCH v5 3/3] lib: rename lib/find_next_bit.c to lib/find_bit.c Yury Norov
2015-02-24 0:40 ` Andrew Morton [this message]
2015-03-08 18:17 ` [PATCH v5 0/3] lib: find_*_bit reimplementation 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=20150223164035.65bb0c11bb17b9a3857e713f@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=chris@chris-wilson.co.uk \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=hannes@stressinduktion.org \
--cc=klimov.linux@gmail.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=linux@rasmusvillemoes.dk \
--cc=msalter@redhat.com \
--cc=takahiro.akashi@linaro.org \
--cc=tgraf@suug.ch \
--cc=valentinrothberg@gmail.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
all inboxes | Powered by JetHome®