linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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.
> 
> 

  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).