From: Daniel Santos <danielfsantos@att.net> To: Michel Lespinasse <walken@google.com> Cc: aarcange@redhat.com, dwmw2@infradead.org, riel@redhat.com, peterz@infradead.org, axboe@kernel.dk, ebiederm@xmission.com, linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org Subject: Re: [PATCH 02/13] rbtree: empty nodes have no color Date: Tue, 10 Jul 2012 05:59:26 -0500 [thread overview] Message-ID: <4FFC0B0E.8070600@att.net> (raw) In-Reply-To: <1341876923-12469-3-git-send-email-walken@google.com> On 07/09/2012 06:35 PM, Michel Lespinasse wrote: > Empty nodes have no color. We can make use of this property to > simplify the code emitted by the RB_EMPTY_NODE and RB_CLEAR_NODE > macros. Also, we can get rid of the rb_init_node function which had > been introduced by commit 88d19cf37952a7e1e38b2bf87a00f0e857e63180 > to avoid some issue with the empty node's color not being initialized. Oh sweet, very glad to see this. I'm addressing a fairly large scope of things in my patches and I didn't want to address this yet, so I'm glad somebody has. :) I *hoped* that gcc would figure out some of the excesses of rb_init_node and and just set rb_parent_color directly to the node address, but better to have actually fixed. As far as RB_EMPTY_NODE, I am using that in my test code (which I haven't posted yet) since I'm testing the actual integrity of a tree and a set of objects after performing insertions & such on it. I'm also using it in some new CONFIG_RBTREE_DEBUG-enabled code. > I'm not sure what the RB_EMPTY_NODE checks in rb_prev() / rb_next() > are doing there, though. axboe introduced them in commit 10fd48f2376d. > The way I see it, the 'empty node' abstraction is only used by rbtree > users to flag nodes that they haven't inserted in any rbtree, so asking > the predecessor or successor of such nodes doesn't make any sense. > > One final rb_init_node() caller was recently added in sysctl code > to implement faster sysctl name lookups. This code doesn't make use > of RB_EMPTY_NODE at all, and from what I could see it only called > rb_init_node() under the mistaken assumption that such initialization > was required before node insertion. That was one of the problems with rb_init_node(). Not being documented, one would assume it's needed unless you study the code more closely. BTW, the current revision of my patches adds some doc comments to struct rb_node since the actual function of rb_parent_color isn't very clear without a lot of study. /** * struct rb_node * @rb_parent_color: Contains the color in the lower 2 bits (although only bit * zero is currently used) and the address of the parent in * the rest (lower 2 bits of address should always be zero on * any arch supported). If the node is initialized and not a * member of any tree, the parent point to its self. If the * node belongs to a tree, but is the root element, the * parent will be NULL. Otherwise, parent will always * point to the parent node in the tree. * @rb_right: Pointer to the right element. * @rb_left: Pointer to the left element. */ That said, there's an extra bit in the rb_parent_color that can be used for some future purpose. Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Santos <danielfsantos@att.net> To: Michel Lespinasse <walken@google.com> Cc: aarcange@redhat.com, dwmw2@infradead.org, riel@redhat.com, peterz@infradead.org, axboe@kernel.dk, ebiederm@xmission.com, linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org Subject: Re: [PATCH 02/13] rbtree: empty nodes have no color Date: Tue, 10 Jul 2012 05:59:26 -0500 [thread overview] Message-ID: <4FFC0B0E.8070600@att.net> (raw) In-Reply-To: <1341876923-12469-3-git-send-email-walken@google.com> On 07/09/2012 06:35 PM, Michel Lespinasse wrote: > Empty nodes have no color. We can make use of this property to > simplify the code emitted by the RB_EMPTY_NODE and RB_CLEAR_NODE > macros. Also, we can get rid of the rb_init_node function which had > been introduced by commit 88d19cf37952a7e1e38b2bf87a00f0e857e63180 > to avoid some issue with the empty node's color not being initialized. Oh sweet, very glad to see this. I'm addressing a fairly large scope of things in my patches and I didn't want to address this yet, so I'm glad somebody has. :) I *hoped* that gcc would figure out some of the excesses of rb_init_node and and just set rb_parent_color directly to the node address, but better to have actually fixed. As far as RB_EMPTY_NODE, I am using that in my test code (which I haven't posted yet) since I'm testing the actual integrity of a tree and a set of objects after performing insertions & such on it. I'm also using it in some new CONFIG_RBTREE_DEBUG-enabled code. > I'm not sure what the RB_EMPTY_NODE checks in rb_prev() / rb_next() > are doing there, though. axboe introduced them in commit 10fd48f2376d. > The way I see it, the 'empty node' abstraction is only used by rbtree > users to flag nodes that they haven't inserted in any rbtree, so asking > the predecessor or successor of such nodes doesn't make any sense. > > One final rb_init_node() caller was recently added in sysctl code > to implement faster sysctl name lookups. This code doesn't make use > of RB_EMPTY_NODE at all, and from what I could see it only called > rb_init_node() under the mistaken assumption that such initialization > was required before node insertion. That was one of the problems with rb_init_node(). Not being documented, one would assume it's needed unless you study the code more closely. BTW, the current revision of my patches adds some doc comments to struct rb_node since the actual function of rb_parent_color isn't very clear without a lot of study. /** * struct rb_node * @rb_parent_color: Contains the color in the lower 2 bits (although only bit * zero is currently used) and the address of the parent in * the rest (lower 2 bits of address should always be zero on * any arch supported). If the node is initialized and not a * member of any tree, the parent point to its self. If the * node belongs to a tree, but is the root element, the * parent will be NULL. Otherwise, parent will always * point to the parent node in the tree. * @rb_right: Pointer to the right element. * @rb_left: Pointer to the left element. */ That said, there's an extra bit in the rb_parent_color that can be used for some future purpose. Daniel -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-07-10 11:01 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-09 23:35 [PATCH 00/13] rbtree updates Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-09 23:35 ` [PATCH 01/13] rbtree: reference Documentation/rbtree.txt for usage instructions Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-10 1:45 ` Rik van Riel 2012-07-10 1:45 ` Rik van Riel 2012-07-09 23:35 ` [PATCH 02/13] rbtree: empty nodes have no color Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-10 10:59 ` Daniel Santos [this message] 2012-07-10 10:59 ` Daniel Santos 2012-07-10 23:10 ` Michel Lespinasse 2012-07-10 23:10 ` Michel Lespinasse 2012-07-09 23:35 ` [PATCH 03/13] rbtree: fix incorrect rbtree node insertion in fs/proc/proc_sysctl.c Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-09 23:35 ` [PATCH 04/13] rbtree: move some implementation details from rbtree.h to rbtree.c Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-10 12:19 ` Michal Nazarewicz 2012-07-10 12:19 ` Michal Nazarewicz 2012-07-10 23:12 ` Michel Lespinasse 2012-07-10 23:12 ` Michel Lespinasse 2012-07-11 15:48 ` Michal Nazarewicz 2012-07-11 15:48 ` Michal Nazarewicz 2012-07-09 23:35 ` [PATCH 05/13] rbtree: performance and correctness test Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-10 12:27 ` Michal Nazarewicz 2012-07-10 12:27 ` Michal Nazarewicz 2012-07-10 23:18 ` Michel Lespinasse 2012-07-10 23:18 ` Michel Lespinasse 2012-07-11 6:14 ` Michel Lespinasse 2012-07-11 6:14 ` Michel Lespinasse 2012-07-11 19:30 ` Daniel Santos 2012-07-11 19:30 ` Daniel Santos 2012-07-09 23:35 ` [PATCH 06/13] rbtree: break out of rb_insert_color loop after tree rotation Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-09 23:35 ` [PATCH 07/13] rbtree: adjust root color in rb_insert_color() only when necessary Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-09 23:35 ` [PATCH 08/13] rbtree: optimize tree rotations in rb_insert_color() Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-09 23:35 ` [PATCH 09/13] rbtree: optimize color flips and parent fetching " Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-09 23:35 ` [PATCH 10/13] rbtree: adjust node color in __rb_erase_color() only when necessary Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-09 23:35 ` [PATCH 11/13] rbtree: optimize case selection logic in __rb_erase_color() Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-09 23:35 ` [PATCH 12/13] rbtree: optimize tree rotations " Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-09 23:35 ` [PATCH 13/13] rbtree: optimize color flips " Michel Lespinasse 2012-07-09 23:35 ` Michel Lespinasse 2012-07-11 13:23 ` [PATCH 00/13] rbtree updates Peter Zijlstra 2012-07-11 13:23 ` Peter Zijlstra 2012-07-12 1:12 ` Michel Lespinasse 2012-07-12 1:12 ` Michel Lespinasse 2012-07-12 14:09 ` Peter Zijlstra 2012-07-12 14:09 ` Peter Zijlstra 2012-07-12 14:12 ` Peter Zijlstra 2012-07-12 14:12 ` Peter Zijlstra 2012-07-13 0:39 ` Michel Lespinasse 2012-07-13 0:39 ` Michel Lespinasse
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=4FFC0B0E.8070600@att.net \ --to=danielfsantos@att.net \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=axboe@kernel.dk \ --cc=daniel.santos@pobox.com \ --cc=dwmw2@infradead.org \ --cc=ebiederm@xmission.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=peterz@infradead.org \ --cc=riel@redhat.com \ --cc=torvalds@linux-foundation.org \ --cc=walken@google.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: linkBe 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.