From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: David Sterba <dsterba@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 7/8] btrfs: relocation: use on-stack iterator in build_backref_tree
Date: Mon, 25 Sep 2023 15:42:24 +0200 [thread overview]
Message-ID: <20230925134224.GL13697@twin.jikos.cz> (raw)
In-Reply-To: <0dc65467-c8ba-4fbb-9475-e753c91d4a77@gmx.com>
On Sat, Sep 23, 2023 at 08:05:25AM +0930, Qu Wenruo wrote:
> On 2023/9/22 20:37, David Sterba wrote:
> > build_backref_tree() is called in a loop by relocate_tree_blocks()
> > for each relocated block. The iterator is allocated and freed repeatedly
> > while we could simply use an on-stack variable to avoid the allocation
> > and remove one more failure case. The stack grows by 48 bytes.
> >
> > This was the only use of btrfs_backref_iter_alloc() so it's changed to
> > be an initializer and btrfs_backref_iter_free() can be removed
> > completely.
> >
> > Signed-off-by: David Sterba <dsterba@suse.com>
> > ---
> > fs/btrfs/backref.c | 26 ++++++++++----------------
> > fs/btrfs/backref.h | 11 ++---------
> > fs/btrfs/relocation.c | 12 ++++++------
> > 3 files changed, 18 insertions(+), 31 deletions(-)
> >
> > diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
> > index 0dc91bf654b5..691b20b47065 100644
> > --- a/fs/btrfs/backref.c
> > +++ b/fs/btrfs/backref.c
> > @@ -2828,26 +2828,20 @@ void free_ipath(struct inode_fs_paths *ipath)
> > kfree(ipath);
> > }
> >
> > -struct btrfs_backref_iter *btrfs_backref_iter_alloc(struct btrfs_fs_info *fs_info)
> > +int btrfs_backref_iter_init(struct btrfs_fs_info *fs_info,
> > + struct btrfs_backref_iter *iter)
> > {
> > - struct btrfs_backref_iter *ret;
> > -
> > - ret = kzalloc(sizeof(*ret), GFP_NOFS);
> > - if (!ret)
> > - return NULL;
> > -
> > - ret->path = btrfs_alloc_path();
> > - if (!ret->path) {
> > - kfree(ret);
> > - return NULL;
> > - }
> > + memset(iter, 0, sizeof(struct btrfs_backref_iter));
> > + iter->path = btrfs_alloc_path();
> > + if (!iter->path)
> > + return -ENOMEM;
>
> We can do one step further, by integrating the btrfs_path into @iter,
> other than re-allocating it again and again.
Possible but needs to be evaluated separately, the size of path is 112
and this starts to become noticeable on the stack.
next prev parent reply other threads:[~2023-09-25 13:49 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-22 11:07 [PATCH 0/8] Minor cleanups in relocation.c David Sterba
2023-09-22 11:07 ` [PATCH 1/8] btrfs: relocation: use more natural types for tree_block bitfields David Sterba
2023-09-22 12:28 ` Johannes Thumshirn
2023-09-22 22:28 ` Qu Wenruo
2023-09-22 11:07 ` [PATCH 2/8] btrfs: relocation: use enum for stages David Sterba
2023-09-22 12:29 ` Johannes Thumshirn
2023-09-22 22:29 ` Qu Wenruo
2023-09-25 13:44 ` David Sterba
2023-09-22 11:07 ` [PATCH 3/8] btrfs: relocation: switch bitfields to bool in reloc_control David Sterba
2023-09-22 12:30 ` Johannes Thumshirn
2023-09-22 22:30 ` Qu Wenruo
2023-09-22 11:07 ` [PATCH 4/8] btrfs: relocation: open code mapping_tree_init David Sterba
2023-09-22 12:31 ` Johannes Thumshirn
2023-09-22 22:31 ` Qu Wenruo
2023-09-22 11:07 ` [PATCH 5/8] btrfs: switch btrfs_backref_cache::is_reloc to bool David Sterba
2023-09-22 12:31 ` Johannes Thumshirn
2023-09-22 22:31 ` Qu Wenruo
2023-09-22 11:07 ` [PATCH 6/8] btrfs: relocation: return bool from btrfs_should_ignore_reloc_root David Sterba
2023-09-22 12:36 ` Johannes Thumshirn
2023-09-22 18:35 ` David Sterba
2023-09-22 22:32 ` Qu Wenruo
2023-09-22 11:07 ` [PATCH 7/8] btrfs: relocation: use on-stack iterator in build_backref_tree David Sterba
2023-09-22 12:46 ` Johannes Thumshirn
2023-09-22 22:35 ` Qu Wenruo
2023-09-25 13:42 ` David Sterba [this message]
2023-10-04 12:35 ` Filipe Manana
2023-10-04 12:46 ` David Sterba
2023-09-22 11:07 ` [PATCH 8/8] btrfs: relocation: constify parameters where possible David Sterba
2023-09-22 12:43 ` Johannes Thumshirn
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=20230925134224.GL13697@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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;
as well as URLs for NNTP newsgroup(s).