From: klimov.linux@gmail.com (Alexey Klimov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] lib: Make _find_next_bit helper function inline
Date: Wed, 29 Jul 2015 16:30:56 +0300 [thread overview]
Message-ID: <1438176656.18723.8.camel@ceres> (raw)
In-Reply-To: <20150728144537.67d46b5714c99d25f0bb33fb@linux-foundation.org>
On ??., 2015-07-28 at 14:45 -0700, Andrew Morton wrote:
> On Wed, 29 Jul 2015 00:23:18 +0300 Yury <yury.norov@gmail.com> wrote:
>
> > But I think, before/after for x86 is needed as well.
>
> That would be nice.
>
> > And why don't you consider '__always_inline__'? Simple inline is only a
> > hint and
> > guarantees nothing.
>
> Yup. My x86_64 compiler just ignores the "inline". When I use
> __always_inline, find_bit.o's text goes from 776 bytes to 863.
> Hopefully we get something in return for that bloat!
On my x86_64 (core-i5 something, with disabled cpufreq) i got following
numbers:
find_next_zero_bit
old new __always_inline
20 21 22
20 21 22
20 22 23
21 21 22
21 21 23
20 21 22
20 21 23
21 22 23
20 22 22
21 21 22
find_next_bit
old new __always_inline
19 21 24
19 22 24
19 22 24
19 21 24
20 22 24
19 21 23
19 21 23
20 21 24
19 22 24
19 21 24
I will re-check on another machine. It's really interesting if
__always_inline makes things better for aarch64 and worse for x86_64. It
will be nice if someone will check it on x86_64 too.
Best regards,
Alexey Klimov.
> Also, if _find_next_bit() benefits from this then _find_next_bit_le()
> will presumably also benefit.
>
>
next prev parent reply other threads:[~2015-07-29 13:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 19:09 [PATCH] lib: Make _find_next_bit helper function inline Cassidy Burden
2015-07-28 21:23 ` Yury
2015-07-28 21:38 ` Yury
2015-07-28 21:45 ` Andrew Morton
2015-07-29 13:30 ` Alexey Klimov [this message]
2015-07-29 20:40 ` Cassidy Burden
2015-08-23 22:53 ` Alexey Klimov
2015-08-29 15:15 ` Yury
2015-08-30 21:47 ` Rasmus Villemoes
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=1438176656.18723.8.camel@ceres \
--to=klimov.linux@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).