From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3.1 3/7] btrfs: relocation: Delay reloc tree deletion after merge_reloc_roots()
Date: Mon, 14 Jan 2019 18:04:40 +0100 [thread overview]
Message-ID: <20190114170440.GC2900@twin.jikos.cz> (raw)
In-Reply-To: <20190107054151.18662-4-wqu@suse.com>
On Mon, Jan 07, 2019 at 01:41:47PM +0800, Qu Wenruo wrote:
> +static int insert_dirty_root(struct btrfs_trans_handle *trans,
> + struct reloc_control *rc,
> + struct btrfs_root *root)
> +{
> + struct rb_node **p = &rc->dirty_roots.rb_node;
> + struct rb_node *parent = NULL;
> + struct dirty_source_root *entry;
> + struct btrfs_root *reloc_root = root->reloc_root;
> + struct btrfs_root_item *reloc_root_item;
> + u64 root_objectid = root->root_key.objectid;
> +
> + /* @root must be a file tree root*/
> + ASSERT(root_objectid != BTRFS_TREE_RELOC_OBJECTID);
> + ASSERT(reloc_root);
> +
> + reloc_root_item = &reloc_root->root_item;
> + memset(&reloc_root_item->drop_progress, 0,
> + sizeof(reloc_root_item->drop_progress));
> + reloc_root_item->drop_level = 0;
> + btrfs_set_root_refs(reloc_root_item, 0);
> + btrfs_update_reloc_root(trans, root);
> +
> + /* We're at relocation route, not writeback route, GFP_KERNEL is OK */
> + entry = kmalloc(sizeof(*entry), GFP_KERNEL);
The open transaction also mandates GFP_NOFS, so that's another thing
to the locks and writeback constraints.
> + if (!entry)
> + return -ENOMEM;
> + btrfs_grab_fs_root(root);
> + entry->root = root;
> + while (*p) {
> + struct dirty_source_root *cur_entry;
> +
> + parent = *p;
> + cur_entry = rb_entry(parent, struct dirty_source_root, node);
> +
> + if (root_objectid < cur_entry->root->root_key.objectid)
> + p = &(*p)->rb_left;
> + else if (root_objectid > cur_entry->root->root_key.objectid)
> + p = &(*p)->rb_right;
Please stick to the coding style, { } around single statement if/else in
case they're chained and there's one multi statement block.
> + else {
> + /* This root is already dirtied */
> + btrfs_put_fs_root(root);
> + kfree(entry);
> + return 0;
> + }
> + }
> + rb_link_node(&entry->node, parent, p);
> + rb_insert_color(&entry->node, &rc->dirty_roots);
> + return 0;
> +}
next prev parent reply other threads:[~2019-01-14 17:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-07 5:41 [PATCH v3.1 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead Qu Wenruo
2019-01-07 5:41 ` [PATCH v3.1 1/7] btrfs: qgroup: Move reserved data account from btrfs_delayed_ref_head to btrfs_qgroup_extent_record Qu Wenruo
2019-01-07 5:41 ` [PATCH v3.1 2/7] btrfs: qgroup: Don't trigger backref walk at delayed ref insert time Qu Wenruo
2019-01-07 5:41 ` [PATCH v3.1 3/7] btrfs: relocation: Delay reloc tree deletion after merge_reloc_roots() Qu Wenruo
2019-01-14 17:04 ` David Sterba [this message]
2019-01-14 17:11 ` David Sterba
2019-01-15 0:44 ` Qu Wenruo
2019-01-14 17:21 ` David Sterba
2019-01-15 0:54 ` Qu Wenruo
2019-01-07 5:41 ` [PATCH v3.1 4/7] btrfs: qgroup: Refactor btrfs_qgroup_trace_subtree_swap() Qu Wenruo
2019-01-07 5:41 ` [PATCH v3.1 5/7] btrfs: qgroup: Introduce per-root swapped blocks infrastructure Qu Wenruo
2019-01-07 5:41 ` [PATCH v3.1 6/7] btrfs: qgroup: Use delayed subtree rescan for balance Qu Wenruo
2019-01-07 5:41 ` [PATCH v3.1 7/7] btrfs: qgroup: Cleanup old subtree swap code Qu Wenruo
2019-01-08 14:27 ` [PATCH v3.1 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead David Sterba
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=20190114170440.GC2900@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@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 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.