All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree
@ 2014-01-27  9:59 Wang Shilong
  2014-01-27  9:59 ` [PATCH v3 2/2] Btrfs: do not export ulist functions Wang Shilong
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Wang Shilong @ 2014-01-27  9:59 UTC (permalink / raw)
  To: linux-btrfs

We are really suffering from now ulist's implementation, some developers
gave their try, and i just gave some of my ideas for things:

 1. use list+rb_tree instead of arrary+rb_tree

 2. add cur_list to iterator rather than ulist structure.

 3. add seqnum into every node when they are added, this is
 used to do selfcheck when iterating node.

I noticed Zach Brown's comments before, long term is to kick off
ulist implementation, however, for now, we need at least avoid
arrary from ulist.

Cc: Liu Bo <bo.li.liu@oracle.com>
Cc: Josef Bacik <jbacik@fb.com>
Cc: Zach Brown <zab@redhat.com>
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
---
v2->v3:
	only do selfchecks with CONFIG_BTRFS_DEBUG enabled(Thanks to Josef!)
	update ulist's comments since they are out of date.
v1->v2:
	add RFC title since this patch needs more reviews and comments.
	fix a used after free bug in ulist_fini().
---
 fs/btrfs/ulist.c | 109 ++++++++++++++++++++++++-------------------------------
 fs/btrfs/ulist.h |  41 +++++++--------------
 2 files changed, 61 insertions(+), 89 deletions(-)

diff --git a/fs/btrfs/ulist.c b/fs/btrfs/ulist.c
index 35f5de9..1c9e2c9 100644
--- a/fs/btrfs/ulist.c
+++ b/fs/btrfs/ulist.c
@@ -7,6 +7,7 @@
 #include <linux/slab.h>
 #include <linux/export.h>
 #include "ulist.h"
+#include "ctree.h"
 
 /*
  * ulist is a generic data structure to hold a collection of unique u64
@@ -14,10 +15,6 @@
  * enumerating it.
  * It is possible to store an auxiliary value along with the key.
  *
- * The implementation is preliminary and can probably be sped up
- * significantly. A first step would be to store the values in an rbtree
- * as soon as ULIST_SIZE is exceeded.
- *
  * A sample usage for ulists is the enumeration of directed graphs without
  * visiting a node twice. The pseudo-code could look like this:
  *
@@ -50,10 +47,11 @@
  */
 void ulist_init(struct ulist *ulist)
 {
-	ulist->nnodes = 0;
-	ulist->nodes = ulist->int_nodes;
-	ulist->nodes_alloced = ULIST_SIZE;
+	INIT_LIST_HEAD(&ulist->nodes);
 	ulist->root = RB_ROOT;
+#ifdef CONFIG_BTRFS_DEBUG
+	ulist->nnodes = 0;
+#endif
 }
 EXPORT_SYMBOL(ulist_init);
 
@@ -66,14 +64,14 @@ EXPORT_SYMBOL(ulist_init);
  */
 void ulist_fini(struct ulist *ulist)
 {
-	/*
-	 * The first ULIST_SIZE elements are stored inline in struct ulist.
-	 * Only if more elements are alocated they need to be freed.
-	 */
-	if (ulist->nodes_alloced > ULIST_SIZE)
-		kfree(ulist->nodes);
-	ulist->nodes_alloced = 0;	/* in case ulist_fini is called twice */
+	struct ulist_node *node;
+	struct ulist_node *next;
+
+	list_for_each_entry_safe(node, next, &ulist->nodes, list) {
+		kfree(node);
+	}
 	ulist->root = RB_ROOT;
+	INIT_LIST_HEAD(&ulist->nodes);
 }
 EXPORT_SYMBOL(ulist_fini);
 
@@ -192,57 +190,31 @@ int ulist_add(struct ulist *ulist, u64 val, u64 aux, gfp_t gfp_mask)
 int ulist_add_merge(struct ulist *ulist, u64 val, u64 aux,
 		    u64 *old_aux, gfp_t gfp_mask)
 {
-	int ret = 0;
-	struct ulist_node *node = NULL;
+	int ret;
+	struct ulist_node *node;
+
 	node = ulist_rbtree_search(ulist, val);
 	if (node) {
 		if (old_aux)
 			*old_aux = node->aux;
 		return 0;
 	}
+	node = kmalloc(sizeof(*node), gfp_mask);
+	if (!node)
+		return -ENOMEM;
 
-	if (ulist->nnodes >= ulist->nodes_alloced) {
-		u64 new_alloced = ulist->nodes_alloced + 128;
-		struct ulist_node *new_nodes;
-		void *old = NULL;
-		int i;
-
-		/*
-		 * if nodes_alloced == ULIST_SIZE no memory has been allocated
-		 * yet, so pass NULL to krealloc
-		 */
-		if (ulist->nodes_alloced > ULIST_SIZE)
-			old = ulist->nodes;
+	node->val = val;
+	node->aux = aux;
+#ifdef CONFIG_BTRFS_DEBUG
+	node->seqnum = ulist->nnodes;
+#endif
 
-		new_nodes = krealloc(old, sizeof(*new_nodes) * new_alloced,
-				     gfp_mask);
-		if (!new_nodes)
-			return -ENOMEM;
-
-		if (!old)
-			memcpy(new_nodes, ulist->int_nodes,
-			       sizeof(ulist->int_nodes));
-
-		ulist->nodes = new_nodes;
-		ulist->nodes_alloced = new_alloced;
-
-		/*
-		 * krealloc actually uses memcpy, which does not copy rb_node
-		 * pointers, so we have to do it ourselves.  Otherwise we may
-		 * be bitten by crashes.
-		 */
-		ulist->root = RB_ROOT;
-		for (i = 0; i < ulist->nnodes; i++) {
-			ret = ulist_rbtree_insert(ulist, &ulist->nodes[i]);
-			if (ret < 0)
-				return ret;
-		}
-	}
-	ulist->nodes[ulist->nnodes].val = val;
-	ulist->nodes[ulist->nnodes].aux = aux;
-	ret = ulist_rbtree_insert(ulist, &ulist->nodes[ulist->nnodes]);
-	BUG_ON(ret);
-	++ulist->nnodes;
+	ret = ulist_rbtree_insert(ulist, node);
+	ASSERT(!ret);
+	list_add_tail(&node->list, &ulist->nodes);
+#ifdef CONFIG_BTRFS_DEBUG
+	ulist->nnodes++;
+#endif
 
 	return 1;
 }
@@ -266,11 +238,26 @@ EXPORT_SYMBOL(ulist_add);
  */
 struct ulist_node *ulist_next(struct ulist *ulist, struct ulist_iterator *uiter)
 {
-	if (ulist->nnodes == 0)
+	struct ulist_node *node;
+
+	if (list_empty(&ulist->nodes))
 		return NULL;
-	if (uiter->i < 0 || uiter->i >= ulist->nnodes)
+	if (uiter->cur_list && uiter->cur_list->next == &ulist->nodes)
 		return NULL;
-
-	return &ulist->nodes[uiter->i++];
+	if (uiter->cur_list) {
+		uiter->cur_list = uiter->cur_list->next;
+	} else {
+		uiter->cur_list = ulist->nodes.next;
+#ifdef CONFIG_BTRFS_DEBUG
+		uiter->i = 0;
+#endif
+	}
+	node = list_entry(uiter->cur_list, struct ulist_node, list);
+#ifdef CONFIG_BTRFS_DEBUG
+	ASSERT(node->seqnum == uiter->i);
+	ASSERT(uiter->i >= 0 && uiter->i < ulist->nnodes);
+	uiter->i++;
+#endif
+	return node;
 }
 EXPORT_SYMBOL(ulist_next);
diff --git a/fs/btrfs/ulist.h b/fs/btrfs/ulist.h
index fb36731..7be97fc 100644
--- a/fs/btrfs/ulist.h
+++ b/fs/btrfs/ulist.h
@@ -17,18 +17,12 @@
  * enumerating it.
  * It is possible to store an auxiliary value along with the key.
  *
- * The implementation is preliminary and can probably be sped up
- * significantly. A first step would be to store the values in an rbtree
- * as soon as ULIST_SIZE is exceeded.
  */
-
-/*
- * number of elements statically allocated inside struct ulist
- */
-#define ULIST_SIZE 16
-
 struct ulist_iterator {
+#ifdef CONFIG_BTRFS_DEBUG
 	int i;
+#endif
+	struct list_head *cur_list;  /* hint to start search */
 };
 
 /*
@@ -37,6 +31,12 @@ struct ulist_iterator {
 struct ulist_node {
 	u64 val;		/* value to store */
 	u64 aux;		/* auxiliary value saved along with the val */
+
+#ifdef CONFIG_BTRFS_DEBUG
+	int seqnum;		/* sequence number this node is added */
+#endif
+
+	struct list_head list;  /* used to link node */
 	struct rb_node rb_node;	/* used to speed up search */
 };
 
@@ -44,26 +44,11 @@ struct ulist {
 	/*
 	 * number of elements stored in list
 	 */
+#ifdef CONFIG_BTRFS_DEBUG
 	unsigned long nnodes;
-
-	/*
-	 * number of nodes we already have room for
-	 */
-	unsigned long nodes_alloced;
-
-	/*
-	 * pointer to the array storing the elements. The first ULIST_SIZE
-	 * elements are stored inline. In this case the it points to int_nodes.
-	 * After exceeding ULIST_SIZE, dynamic memory is allocated.
-	 */
-	struct ulist_node *nodes;
-
+#endif
+	struct list_head nodes;
 	struct rb_root root;
-
-	/*
-	 * inline storage space for the first ULIST_SIZE entries
-	 */
-	struct ulist_node int_nodes[ULIST_SIZE];
 };
 
 void ulist_init(struct ulist *ulist);
@@ -77,6 +62,6 @@ int ulist_add_merge(struct ulist *ulist, u64 val, u64 aux,
 struct ulist_node *ulist_next(struct ulist *ulist,
 			      struct ulist_iterator *uiter);
 
-#define ULIST_ITER_INIT(uiter) ((uiter)->i = 0)
+#define ULIST_ITER_INIT(uiter) ((uiter)->cur_list = NULL)
 
 #endif
-- 
1.8.3.1


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH v3 2/2] Btrfs: do not export ulist functions
  2014-01-27  9:59 [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree Wang Shilong
@ 2014-01-27  9:59 ` Wang Shilong
  2014-01-27 16:30   ` David Sterba
  2014-01-27  9:59 ` [PATCH] Btrfs: allocate ulist with a slab allocator Wang Shilong
  2014-01-28 15:53 ` [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree Josef Bacik
  2 siblings, 1 reply; 9+ messages in thread
From: Wang Shilong @ 2014-01-27  9:59 UTC (permalink / raw)
  To: linux-btrfs

There are not any users that use ulist except Btrfs,don't
export them.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
---
v2->v3: none.
v1->v2: make ulist_fini() static since it is not called anywhere.
---
 fs/btrfs/ulist.c | 10 +---------
 fs/btrfs/ulist.h |  1 -
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/fs/btrfs/ulist.c b/fs/btrfs/ulist.c
index 1c9e2c9..84ea442 100644
--- a/fs/btrfs/ulist.c
+++ b/fs/btrfs/ulist.c
@@ -5,7 +5,6 @@
  */
 
 #include <linux/slab.h>
-#include <linux/export.h>
 #include "ulist.h"
 #include "ctree.h"
 
@@ -53,7 +52,6 @@ void ulist_init(struct ulist *ulist)
 	ulist->nnodes = 0;
 #endif
 }
-EXPORT_SYMBOL(ulist_init);
 
 /**
  * ulist_fini - free up additionally allocated memory for the ulist
@@ -62,7 +60,7 @@ EXPORT_SYMBOL(ulist_init);
  * This is useful in cases where the base 'struct ulist' has been statically
  * allocated.
  */
-void ulist_fini(struct ulist *ulist)
+static void ulist_fini(struct ulist *ulist)
 {
 	struct ulist_node *node;
 	struct ulist_node *next;
@@ -73,7 +71,6 @@ void ulist_fini(struct ulist *ulist)
 	ulist->root = RB_ROOT;
 	INIT_LIST_HEAD(&ulist->nodes);
 }
-EXPORT_SYMBOL(ulist_fini);
 
 /**
  * ulist_reinit - prepare a ulist for reuse
@@ -87,7 +84,6 @@ void ulist_reinit(struct ulist *ulist)
 	ulist_fini(ulist);
 	ulist_init(ulist);
 }
-EXPORT_SYMBOL(ulist_reinit);
 
 /**
  * ulist_alloc - dynamically allocate a ulist
@@ -106,7 +102,6 @@ struct ulist *ulist_alloc(gfp_t gfp_mask)
 
 	return ulist;
 }
-EXPORT_SYMBOL(ulist_alloc);
 
 /**
  * ulist_free - free dynamically allocated ulist
@@ -121,7 +116,6 @@ void ulist_free(struct ulist *ulist)
 	ulist_fini(ulist);
 	kfree(ulist);
 }
-EXPORT_SYMBOL(ulist_free);
 
 static struct ulist_node *ulist_rbtree_search(struct ulist *ulist, u64 val)
 {
@@ -218,7 +212,6 @@ int ulist_add_merge(struct ulist *ulist, u64 val, u64 aux,
 
 	return 1;
 }
-EXPORT_SYMBOL(ulist_add);
 
 /**
  * ulist_next - iterate ulist
@@ -260,4 +253,3 @@ struct ulist_node *ulist_next(struct ulist *ulist, struct ulist_iterator *uiter)
 #endif
 	return node;
 }
-EXPORT_SYMBOL(ulist_next);
diff --git a/fs/btrfs/ulist.h b/fs/btrfs/ulist.h
index 7be97fc..154117d 100644
--- a/fs/btrfs/ulist.h
+++ b/fs/btrfs/ulist.h
@@ -52,7 +52,6 @@ struct ulist {
 };
 
 void ulist_init(struct ulist *ulist);
-void ulist_fini(struct ulist *ulist);
 void ulist_reinit(struct ulist *ulist);
 struct ulist *ulist_alloc(gfp_t gfp_mask);
 void ulist_free(struct ulist *ulist);
-- 
1.8.3.1


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH] Btrfs: allocate ulist with a slab allocator
  2014-01-27  9:59 [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree Wang Shilong
  2014-01-27  9:59 ` [PATCH v3 2/2] Btrfs: do not export ulist functions Wang Shilong
@ 2014-01-27  9:59 ` Wang Shilong
  2014-01-27 16:39   ` David Sterba
  2014-01-28 15:53 ` [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree Josef Bacik
  2 siblings, 1 reply; 9+ messages in thread
From: Wang Shilong @ 2014-01-27  9:59 UTC (permalink / raw)
  To: linux-btrfs

Walking backrefs is heavily relying on ulist, so it is better
to allocate ulist with a slab allocator especially with autodefrag
and quota enabled.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
---
 fs/btrfs/super.c |  7 +++++++
 fs/btrfs/ulist.c | 22 ++++++++++++++++++++--
 fs/btrfs/ulist.h |  2 ++
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 461e41c..1a9ac6d 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1906,6 +1906,10 @@ static int __init init_btrfs_fs(void)
 	if (err)
 		goto free_prelim_ref;
 
+	err = btrfs_ulist_init();
+	if (err)
+		goto free_ulist;
+
 	err = btrfs_interface_init();
 	if (err)
 		goto free_delayed_ref;
@@ -1926,6 +1930,8 @@ static int __init init_btrfs_fs(void)
 
 unregister_ioctl:
 	btrfs_interface_exit();
+free_ulist:
+	btrfs_ulist_exit();
 free_prelim_ref:
 	btrfs_prelim_ref_exit();
 free_delayed_ref:
@@ -1955,6 +1961,7 @@ static void __exit exit_btrfs_fs(void)
 	btrfs_auto_defrag_exit();
 	btrfs_delayed_inode_exit();
 	btrfs_prelim_ref_exit();
+	btrfs_ulist_exit();
 	ordered_data_exit();
 	extent_map_exit();
 	extent_io_exit();
diff --git a/fs/btrfs/ulist.c b/fs/btrfs/ulist.c
index 84ea442..bf9127d 100644
--- a/fs/btrfs/ulist.c
+++ b/fs/btrfs/ulist.c
@@ -8,6 +8,7 @@
 #include "ulist.h"
 #include "ctree.h"
 
+static struct kmem_cache *btrfs_ulist_cache;
 /*
  * ulist is a generic data structure to hold a collection of unique u64
  * values. The only operations it supports is adding to the list and
@@ -66,7 +67,7 @@ static void ulist_fini(struct ulist *ulist)
 	struct ulist_node *next;
 
 	list_for_each_entry_safe(node, next, &ulist->nodes, list) {
-		kfree(node);
+		kmem_cache_free(btrfs_ulist_cache, node);
 	}
 	ulist->root = RB_ROOT;
 	INIT_LIST_HEAD(&ulist->nodes);
@@ -156,6 +157,23 @@ static int ulist_rbtree_insert(struct ulist *ulist, struct ulist_node *ins)
 	return 0;
 }
 
+int __init btrfs_ulist_init(void)
+{
+	btrfs_ulist_cache = kmem_cache_create("btrfs_ulist_cache",
+					sizeof(struct ulist_node), 0,
+					SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD,
+					NULL);
+	if (!btrfs_ulist_cache)
+		return -ENOMEM;
+	return 0;
+}
+
+void btrfs_ulist_exit(void)
+{
+	if (btrfs_ulist_cache)
+		kmem_cache_destroy(btrfs_ulist_cache);
+}
+
 /**
  * ulist_add - add an element to the ulist
  * @ulist:	ulist to add the element to
@@ -193,7 +211,7 @@ int ulist_add_merge(struct ulist *ulist, u64 val, u64 aux,
 			*old_aux = node->aux;
 		return 0;
 	}
-	node = kmalloc(sizeof(*node), gfp_mask);
+	node = kmem_cache_alloc(btrfs_ulist_cache, gfp_mask);
 	if (!node)
 		return -ENOMEM;
 
diff --git a/fs/btrfs/ulist.h b/fs/btrfs/ulist.h
index 154117d..d094621 100644
--- a/fs/btrfs/ulist.h
+++ b/fs/btrfs/ulist.h
@@ -51,6 +51,8 @@ struct ulist {
 	struct rb_root root;
 };
 
+int __init btrfs_ulist_init(void);
+void btrfs_ulist_exit(void);
 void ulist_init(struct ulist *ulist);
 void ulist_reinit(struct ulist *ulist);
 struct ulist *ulist_alloc(gfp_t gfp_mask);
-- 
1.8.3.1


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 2/2] Btrfs: do not export ulist functions
  2014-01-27  9:59 ` [PATCH v3 2/2] Btrfs: do not export ulist functions Wang Shilong
@ 2014-01-27 16:30   ` David Sterba
  0 siblings, 0 replies; 9+ messages in thread
From: David Sterba @ 2014-01-27 16:30 UTC (permalink / raw)
  To: Wang Shilong; +Cc: linux-btrfs

On Mon, Jan 27, 2014 at 05:59:48PM +0800, Wang Shilong wrote:
> There are not any users that use ulist except Btrfs,don't
> export them.
> 
> Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>

Agreed,
Reviewed-by: David Sterba <dsterba@suse.cz>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] Btrfs: allocate ulist with a slab allocator
  2014-01-27  9:59 ` [PATCH] Btrfs: allocate ulist with a slab allocator Wang Shilong
@ 2014-01-27 16:39   ` David Sterba
  0 siblings, 0 replies; 9+ messages in thread
From: David Sterba @ 2014-01-27 16:39 UTC (permalink / raw)
  To: Wang Shilong; +Cc: linux-btrfs

On Mon, Jan 27, 2014 at 05:59:49PM +0800, Wang Shilong wrote:
> --- a/fs/btrfs/ulist.c
> +++ b/fs/btrfs/ulist.c
> @@ -156,6 +157,23 @@ static int ulist_rbtree_insert(struct ulist *ulist, struct ulist_node *ins)
>  	return 0;
>  }
>  
> +int __init btrfs_ulist_init(void)
> +{
> +	btrfs_ulist_cache = kmem_cache_create("btrfs_ulist_cache",

Please use the cache name that matches the structure name if possible,
or with the btrfs_ prefix, ie. b

	btrfs_ulist_cache = kmem_cache_create("btrfs_ulist_node",

> +					sizeof(struct ulist_node), 0,
> +					SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD,
> +					NULL);

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree
  2014-01-27  9:59 [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree Wang Shilong
  2014-01-27  9:59 ` [PATCH v3 2/2] Btrfs: do not export ulist functions Wang Shilong
  2014-01-27  9:59 ` [PATCH] Btrfs: allocate ulist with a slab allocator Wang Shilong
@ 2014-01-28 15:53 ` Josef Bacik
  2014-01-28 16:03   ` Wang Shilong
  2 siblings, 1 reply; 9+ messages in thread
From: Josef Bacik @ 2014-01-28 15:53 UTC (permalink / raw)
  To: Wang Shilong, linux-btrfs


On 01/27/2014 04:59 AM, Wang Shilong wrote:
> We are really suffering from now ulist's implementation, some developers
> gave their try, and i just gave some of my ideas for things:
>
>   1. use list+rb_tree instead of arrary+rb_tree
>
>   2. add cur_list to iterator rather than ulist structure.
>
>   3. add seqnum into every node when they are added, this is
>   used to do selfcheck when iterating node.
>
> I noticed Zach Brown's comments before, long term is to kick off
> ulist implementation, however, for now, we need at least avoid
> arrary from ulist.
>
> Cc: Liu Bo <bo.li.liu@oracle.com>
> Cc: Josef Bacik <jbacik@fb.com>
> Cc: Zach Brown <zab@redhat.com>
> Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
> ---
> v2->v3:
> 	only do selfchecks with CONFIG_BTRFS_DEBUG enabled(Thanks to Josef!)
> 	update ulist's comments since they are out of date.
> v1->v2:
> 	add RFC title since this patch needs more reviews and comments.
> 	fix a used after free bug in ulist_fini().

I like the patch but it doesn't build since things like qgroups rely on 
ulist->nnodes.  You need to fix that in your patch and make sure this 
stuff compiles.  Thanks,

Josef

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree
  2014-01-28 15:53 ` [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree Josef Bacik
@ 2014-01-28 16:03   ` Wang Shilong
  2014-01-28 16:08     ` Josef Bacik
  0 siblings, 1 reply; 9+ messages in thread
From: Wang Shilong @ 2014-01-28 16:03 UTC (permalink / raw)
  To: Josef Bacik; +Cc: Wang Shilong, linux-btrfs


Hello Josef,

> 
> On 01/27/2014 04:59 AM, Wang Shilong wrote:
>> We are really suffering from now ulist's implementation, some developers
>> gave their try, and i just gave some of my ideas for things:
>> 
>>  1. use list+rb_tree instead of arrary+rb_tree
>> 
>>  2. add cur_list to iterator rather than ulist structure.
>> 
>>  3. add seqnum into every node when they are added, this is
>>  used to do selfcheck when iterating node.
>> 
>> I noticed Zach Brown's comments before, long term is to kick off
>> ulist implementation, however, for now, we need at least avoid
>> arrary from ulist.
>> 
>> Cc: Liu Bo <bo.li.liu@oracle.com>
>> Cc: Josef Bacik <jbacik@fb.com>
>> Cc: Zach Brown <zab@redhat.com>
>> Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
>> ---
>> v2->v3:
>> 	only do selfchecks with CONFIG_BTRFS_DEBUG enabled(Thanks to Josef!)
>> 	update ulist's comments since they are out of date.
>> v1->v2:
>> 	add RFC title since this patch needs more reviews and comments.
>> 	fix a used after free bug in ulist_fini().
> 
> I like the patch but it doesn't build since things like qgroups rely on ulist->nnodes.  You need to fix that in your patch and make sure this stuff compiles.  Thanks,

Sorry about if it did not compile.

but I really compiled and tested it  in my box, did you apply your qgroup patches?
This patch is based on btrfs-next without your previous qgroup patches.

Anyway i will double check it….. 

Thanks,
Wang
> 
> Josef
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree
  2014-01-28 16:03   ` Wang Shilong
@ 2014-01-28 16:08     ` Josef Bacik
  2014-01-28 16:21       ` Wang Shilong
  0 siblings, 1 reply; 9+ messages in thread
From: Josef Bacik @ 2014-01-28 16:08 UTC (permalink / raw)
  To: Wang Shilong; +Cc: Wang Shilong, linux-btrfs


On 01/28/2014 11:03 AM, Wang Shilong wrote:
> Hello Josef,
>
>> On 01/27/2014 04:59 AM, Wang Shilong wrote:
>>> We are really suffering from now ulist's implementation, some developers
>>> gave their try, and i just gave some of my ideas for things:
>>>
>>>   1. use list+rb_tree instead of arrary+rb_tree
>>>
>>>   2. add cur_list to iterator rather than ulist structure.
>>>
>>>   3. add seqnum into every node when they are added, this is
>>>   used to do selfcheck when iterating node.
>>>
>>> I noticed Zach Brown's comments before, long term is to kick off
>>> ulist implementation, however, for now, we need at least avoid
>>> arrary from ulist.
>>>
>>> Cc: Liu Bo <bo.li.liu@oracle.com>
>>> Cc: Josef Bacik <jbacik@fb.com>
>>> Cc: Zach Brown <zab@redhat.com>
>>> Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
>>> ---
>>> v2->v3:
>>> 	only do selfchecks with CONFIG_BTRFS_DEBUG enabled(Thanks to Josef!)
>>> 	update ulist's comments since they are out of date.
>>> v1->v2:
>>> 	add RFC title since this patch needs more reviews and comments.
>>> 	fix a used after free bug in ulist_fini().
>> I like the patch but it doesn't build since things like qgroups rely on ulist->nnodes.  You need to fix that in your patch and make sure this stuff compiles.  Thanks,
> Sorry about if it did not compile.
>
> but I really compiled and tested it  in my box, did you apply your qgroup patches?
> This patch is based on btrfs-next without your previous qgroup patches.
>
> Anyway i will double check it…..
>
Yeah I thought I was doing something wrong but I'm definitely on my 
master branch which doesn't have my qgroup patches in it.  If it's still 
working for you now just wait a bit for me to push out this next update 
and rebase onto it and resend.  Thanks,

Josef

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree
  2014-01-28 16:08     ` Josef Bacik
@ 2014-01-28 16:21       ` Wang Shilong
  0 siblings, 0 replies; 9+ messages in thread
From: Wang Shilong @ 2014-01-28 16:21 UTC (permalink / raw)
  To: Josef Bacik; +Cc: Wang Shilong, linux-btrfs


> 
> On 01/28/2014 11:03 AM, Wang Shilong wrote:
>> Hello Josef,
>> 
>>> On 01/27/2014 04:59 AM, Wang Shilong wrote:
>>>> We are really suffering from now ulist's implementation, some developers
>>>> gave their try, and i just gave some of my ideas for things:
>>>> 
>>>>  1. use list+rb_tree instead of arrary+rb_tree
>>>> 
>>>>  2. add cur_list to iterator rather than ulist structure.
>>>> 
>>>>  3. add seqnum into every node when they are added, this is
>>>>  used to do selfcheck when iterating node.
>>>> 
>>>> I noticed Zach Brown's comments before, long term is to kick off
>>>> ulist implementation, however, for now, we need at least avoid
>>>> arrary from ulist.
>>>> 
>>>> Cc: Liu Bo <bo.li.liu@oracle.com>
>>>> Cc: Josef Bacik <jbacik@fb.com>
>>>> Cc: Zach Brown <zab@redhat.com>
>>>> Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
>>>> ---
>>>> v2->v3:
>>>> 	only do selfchecks with CONFIG_BTRFS_DEBUG enabled(Thanks to Josef!)
>>>> 	update ulist's comments since they are out of date.
>>>> v1->v2:
>>>> 	add RFC title since this patch needs more reviews and comments.
>>>> 	fix a used after free bug in ulist_fini().
>>> I like the patch but it doesn't build since things like qgroups rely on ulist->nnodes.  You need to fix that in your patch and make sure this stuff compiles.  Thanks,
>> Sorry about if it did not compile.
>> 
>> but I really compiled and tested it  in my box, did you apply your qgroup patches?
>> This patch is based on btrfs-next without your previous qgroup patches.
>> 
>> Anyway i will double check it…..
>> 
> Yeah I thought I was doing something wrong but I'm definitely on my master branch which doesn't have my qgroup patches in it.  If it's still working for you now just wait a bit for me to push out this next update and rebase onto it and resend.  Thanks,
> 
oops, i noticed what was wrong here, i am sorry for inconvenience  for you!~_~
I will resend this patch right now.

Wang
> Josef


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-01-28 16:21 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-27  9:59 [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree Wang Shilong
2014-01-27  9:59 ` [PATCH v3 2/2] Btrfs: do not export ulist functions Wang Shilong
2014-01-27 16:30   ` David Sterba
2014-01-27  9:59 ` [PATCH] Btrfs: allocate ulist with a slab allocator Wang Shilong
2014-01-27 16:39   ` David Sterba
2014-01-28 15:53 ` [PATCH v3 1/2] Btrfs: rework ulist with list+rb_tree Josef Bacik
2014-01-28 16:03   ` Wang Shilong
2014-01-28 16:08     ` Josef Bacik
2014-01-28 16:21       ` Wang Shilong

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.