From: David Sterba <dsterba@suse.cz>
To: Nikolay Borisov <nborisov@suse.com>
Cc: David Sterba <dsterba@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/3] btrfs: add __cold attribute to more functions
Date: Fri, 4 Oct 2019 12:56:44 +0200 [thread overview]
Message-ID: <20191004105644.GW2751@twin.jikos.cz> (raw)
In-Reply-To: <cc58a307-c3af-f2e1-b309-016c5bed5088@suse.com>
On Wed, Oct 02, 2019 at 01:52:16PM +0300, Nikolay Borisov wrote:
> On 1.10.19 г. 20:57 ч., David Sterba wrote:
> > The attribute can mark functions supposed to be called rarely if at all
> > and the text can be moved to sections far from the other code. The
> > attribute has been added to several functions already, this patch is
> > based on hints given by gcc -Wsuggest-attribute=cold.
> >
> > The net effect of this patch is decrease of btrfs.ko by 1000-1300,
> > depending on the config options.
> >
> > Signed-off-by: David Sterba <dsterba@suse.com>
> > ---
> > fs/btrfs/disk-io.c | 4 ++--
> > fs/btrfs/disk-io.h | 4 ++--
> > fs/btrfs/super.c | 2 +-
> > fs/btrfs/volumes.c | 2 +-
> > 4 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> > index e335fa4c4d1d..04d86e11117b 100644
> > --- a/fs/btrfs/disk-io.c
> > +++ b/fs/btrfs/disk-io.c
> > @@ -2583,7 +2583,7 @@ static int btrfs_validate_write_super(struct btrfs_fs_info *fs_info,
> > return ret;
> > }
> >
> > -int open_ctree(struct super_block *sb,
> > +int __cold open_ctree(struct super_block *sb,
>
> According to the documentation
> (https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html) of gcc
> attributes are placed in the declaration of a function (3rd paragraph):
>
>
> "Function attributes are introduced by the __attribute__ keyword in the
> declaration of a function, ..."
I'd rather keep the attributes to declaration and definition so it's in
sync and looks consistent without further questions.
> > +void __cold btrfs_printk(const struct btrfs_fs_info *fs_info, const char *fmt, ...)
> > {
>
> Is printk really cold though? It's used in the various print helpers,
> even for info level print which might not be rare once the fs is
> mounted? What's a possible negative effect of this size optimisation -
> runtime cost?
Messages are printed rarely under normal circumstances, ie. a message
once in a few minutes maybe. The penalty of loading the code into caches
is IMO justified here, there's not much chance of reusing the cache hot
code. And that it also involves all other helpers is kind of
intentional.
A very frequent pattern:
x = find_some_structure();
if (!x) {
btrfs_err("there is a problem");
ret = -EUCLEAN;
goto out_error;
}
In this case the cold attribute is another hint to the compiler that the
whole code block following the 'if' is cold and can be rearranged out of
the way.
If you have counter examples for printk-related functions that are on a
hot path in btrfs, I'd like to hear about them. To move them out of the
that hot path :)
next prev parent reply other threads:[~2019-10-04 10:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-01 17:57 [PATCH 0/3] Coldify, constify, purify (function attributes) David Sterba
2019-10-01 17:57 ` [PATCH 1/3] btrfs: add __cold attribute to more functions David Sterba
2019-10-02 10:52 ` Nikolay Borisov
2019-10-04 10:56 ` David Sterba [this message]
2019-10-01 17:57 ` [PATCH 2/3] btrfs: add const function attribute David Sterba
2019-10-02 11:07 ` Nikolay Borisov
2019-10-04 11:01 ` David Sterba
2019-10-01 17:57 ` [PATCH 3/3] btrfs: add __pure attribute to functions David Sterba
2019-10-02 11:09 ` Nikolay Borisov
2019-10-01 17:57 ` [PATCH 0/3] Coldify, constify, purify (function attributes) David Sterba
2019-10-02 12:20 ` Nikolay Borisov
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=20191004105644.GW2751@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@suse.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