public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Gabriel Niebler <gniebler@suse.com>, linux-btrfs@vger.kernel.org
Cc: dsterba@suse.com
Subject: Re: [PATCH v2] btrfs: Turn delayed_nodes_tree into an XArray
Date: Wed, 13 Apr 2022 16:34:18 +0300	[thread overview]
Message-ID: <c3347f72-0737-38bc-0fd7-70fa7bb272b2@suse.com> (raw)
In-Reply-To: <20220412123546.30478-1-gniebler@suse.com>



On 12.04.22 г. 15:35 ч., Gabriel Niebler wrote:
> … in the btrfs_root struct. Also adjust all usages of this object to use
> the XArray API.
> 
> Signed-off-by: Gabriel Niebler <gniebler@suse.com>
> ---
> 
> Notes:
>      XArrays offer a somewhat nicer API than radix trees and were implemented
>      specifically to replace the latter. They utilize the exact same underlying
>      data structure, but their API is notionally easier to use, as it provides
>      array semantics to the user of radix trees. The higher level API also
>      takes care of locking, adding even more ease of use.
>      
>      The btrfs code uses radix trees in several places. This patch only
>      converts the `delayed_nodes_tree` member of the btrfs_root struct.
>      
>      It survived a complete fstests run.
> 
>   fs/btrfs/ctree.h         |  4 ++--
>   fs/btrfs/delayed-inode.c | 48 ++++++++++++++++++----------------------
>   fs/btrfs/disk-io.c       |  2 +-
>   fs/btrfs/inode.c         |  2 +-
>   4 files changed, 26 insertions(+), 30 deletions(-)
> 
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index b7631b88426e..9377dded9679 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -1224,10 +1224,10 @@ struct btrfs_root {
>   	struct rb_root inode_tree;
>   
>   	/*
> -	 * radix tree that keeps track of delayed nodes of every inode,
> +	 * XArray that keeps track of delayed nodes of every inode,
>   	 * protected by inode_lock
>   	 */
> -	struct radix_tree_root delayed_nodes_tree;
> +	struct xarray delayed_nodes;
>   	/*
>   	 * right now this just gets used so that a root has its own devid
>   	 * for stat.  It may be used for more later
> diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
> index 748bf6b0d860..89e1c39c2aef 100644
> --- a/fs/btrfs/delayed-inode.c
> +++ b/fs/btrfs/delayed-inode.c
> @@ -78,7 +78,7 @@ static struct btrfs_delayed_node *btrfs_get_delayed_node(
>   	}
>   
>   	spin_lock(&root->inode_lock);
> -	node = radix_tree_lookup(&root->delayed_nodes_tree, ino);
> +	node = xa_load(&root->delayed_nodes, (unsigned long)ino);

Isn't this problematic, because  you'd be truncating the ino in case we 
have a number which is larger than unsigned long. For architectures 
which use long as a 64 bit type this cast is a noop since u64 is defined 
as unsigned long (via typedef unsigned long __u64; typedef __u64 u64). 
But on arches which use long long for their 64bit type then this would 
truncate the ino number, so I think this cast is redundant. In any case 
the code is broken for u64 for arches which use long long and as the 
author of xarray put it just now:

<willy> yup.  It's not a great data structure for storing u64s in

However, looking at the existing radix_tree_insert the index is also an 
unsigned long. TLDR is remove the cast.

>   
>   	if (node) {
>   		if (btrfs_inode->delayed_node) {

<snip>


>   	return node;
>   }

<snip>

> @@ -1870,29 +1863,32 @@ void btrfs_kill_delayed_inode_items(struct btrfs_inode *inode)
>   
>   void btrfs_kill_all_delayed_nodes(struct btrfs_root *root)
>   {
> -	u64 inode_id = 0;
> +	unsigned long index;
> +	struct btrfs_delayed_node *delayed_node;
>   	struct btrfs_delayed_node *delayed_nodes[8];
>   	int i, n;
>   
>   	while (1) {
>   		spin_lock(&root->inode_lock);
> -		n = radix_tree_gang_lookup(&root->delayed_nodes_tree,
> -					   (void **)delayed_nodes, inode_id,
> -					   ARRAY_SIZE(delayed_nodes));
> -		if (!n) {
> +		if (xa_empty(&root->delayed_nodes)) {
>   			spin_unlock(&root->inode_lock);
>   			break;
>   		}
>   
> -		inode_id = delayed_nodes[n - 1]->inode_id + 1;
> -		for (i = 0; i < n; i++) {
> +		n = 0;
> +		xa_for_each_start(&root->delayed_nodes, index,
> +				  delayed_node, index) {

Here index is used not only as the index of the current entry but also 
as the "start from this index". But you are not actually initializing it 
so index has garbage on the first iteration. If you want to start from 
the 0th index then you should initialize it when defining it.

>   			/*
>   			 * Don't increase refs in case the node is dead and
>   			 * about to be removed from the tree in the loop below
>   			 */
> -			if (!refcount_inc_not_zero(&delayed_nodes[i]->refs))
> -				delayed_nodes[i] = NULL;
> +			if (!refcount_inc_not_zero(&delayed_node->refs))
> +				delayed_nodes[n] = NULL;

This is broken. What the original code did was query up to 8 delayed 
nodes at a time and and then for every node which got written into the 
delayed_nodes array it incremented the refcount so that later the nodes 
can be destroyed outside of spin_unlock. In your code you don't write 
the node into the local delayed_nodes array, meaning the for() loop 
never frees anything.

> +			n++;
> +			if (n >= ARRAY_SIZE(delayed_nodes))
> +				break;
>   		}
> +		index++;
>   		spin_unlock(&root->inode_lock);
>   
>   		for (i = 0; i < n; i++) {

<snip>

  reply	other threads:[~2022-04-13 13:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-12 12:35 [PATCH v2] btrfs: Turn delayed_nodes_tree into an XArray Gabriel Niebler
2022-04-13 13:34 ` Nikolay Borisov [this message]
2022-04-14  9:26   ` Gabriel Niebler
2022-04-13 14:14 ` David Sterba
2022-04-14  9:39   ` Gabriel Niebler

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=c3347f72-0737-38bc-0fd7-70fa7bb272b2@suse.com \
    --to=nborisov@suse.com \
    --cc=dsterba@suse.com \
    --cc=gniebler@suse.com \
    --cc=linux-btrfs@vger.kernel.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