From: David Laight <David.Laight@ACULAB.COM>
To: 'Andy Shevchenko' <andriy.shevchenko@linux.intel.com>,
Yury Norov <yury.norov@gmail.com>
Cc: "linux-m68k@lists.linux-m68k.org"
<linux-m68k@lists.linux-m68k.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
"Rich Felker" <dalias@libc.org>, Arnd Bergmann <arnd@arndb.de>,
Dennis Zhou <dennis@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
David Sterba <dsterba@suse.com>,
"Stefano Brivio" <sbrivio@redhat.com>,
"Ma, Jianpeng" <jianpeng.ma@intel.com>,
"Wei Yang" <richard.weiyang@linux.alibaba.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Joe Perches <joe@perches.com>
Subject: RE: [PATCH 7/8] lib: add fast path for find_next_*_bit()
Date: Mon, 1 Feb 2021 16:02:30 +0000 [thread overview]
Message-ID: <e9c66d506a614a7e95d039bea325c241@AcuMS.aculab.com> (raw)
In-Reply-To: <YBgG35UTDLpVSYWV@smile.fi.intel.com>
From: Andy Shevchenko
> Sent: 01 February 2021 13:49
>
> On Sat, Jan 30, 2021 at 11:17:18AM -0800, Yury Norov wrote:
> > Similarly to bitmap functions, find_next_*_bit() users will benefit
> > if we'll handle a case of bitmaps that fit into a single word. In the
> > very best case, the compiler may replace a function call with a
> > single ffs or ffz instruction.
>
> Would be nice to have the examples how it reduces the actual code size (based
> on the existing code in kernel, especially in widely used frameworks /
> subsystems, like PCI).
I bet it makes the kernel bigger but very slightly faster.
But the fact that the wrappers end up in the i-cache may
mean that inlining actually makes it slower for some calling
sequences.
If a bitmap fits in a single word (as a compile-time constant)
then you should (probably) be using different functions if
you care about performance.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-02-01 16:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-30 19:17 [RESEND PATCH v2 0/6] lib/find_bit: fast path for small bitmaps Yury Norov
2021-01-30 19:17 ` [PATCH 1/8] tools: disable -Wno-type-limits Yury Norov
2021-01-30 19:17 ` [PATCH 2/8] tools: bitmap: sync function declarations with linux kernel Yury Norov
2021-01-30 19:17 ` [PATCH 3/8] arch: rearrange headers inclusion order in asm/bitops for m68k and sh Yury Norov
2021-01-30 19:17 ` [PATCH 4/8] lib: introduce BITS_{FIRST,LAST} macro Yury Norov
2021-02-01 13:42 ` Andy Shevchenko
2021-01-30 19:17 ` [PATCH 5/8] bitsperlong.h: introduce SMALL_CONST() macro Yury Norov
2021-02-01 13:45 ` Andy Shevchenko
2021-02-02 7:10 ` Yury Norov
2021-01-30 19:17 ` [PATCH 6/8] lib: inline _find_next_bit() wrappers Yury Norov
2021-02-01 13:47 ` Andy Shevchenko
2021-02-02 7:13 ` Yury Norov
2021-01-30 19:17 ` [PATCH 7/8] lib: add fast path for find_next_*_bit() Yury Norov
2021-02-01 13:49 ` Andy Shevchenko
2021-02-01 16:02 ` David Laight [this message]
2021-02-01 16:22 ` 'Andy Shevchenko'
2021-02-02 7:02 ` Yury Norov
2021-01-30 19:17 ` [PATCH 8/8] lib: add fast path for find_first_*_bit() and find_last_bit() Yury Norov
2021-02-01 13:50 ` Andy Shevchenko
2021-02-15 21:30 ` [RESEND PATCH v2 0/6] lib/find_bit: fast path for small bitmaps Yury Norov
2021-02-16 9:14 ` Andy Shevchenko
2021-02-16 18:00 ` Yury Norov
2021-02-17 10:33 ` Andy Shevchenko
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=e9c66d506a614a7e95d039bea325c241@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=dalias@libc.org \
--cc=dennis@kernel.org \
--cc=dsterba@suse.com \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=jianpeng.ma@intel.com \
--cc=joe@perches.com \
--cc=jpoimboe@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-sh@vger.kernel.org \
--cc=richard.weiyang@linux.alibaba.com \
--cc=sbrivio@redhat.com \
--cc=wsa+renesas@sang-engineering.com \
--cc=ysato@users.sourceforge.jp \
--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.