Fri, Nov 13
Oct 2 2020
Sep 29 2020
Sep 15 2020
Sep 2 2020
Sep 1 2020
Aug 24 2020
Jul 25 2020
Jul 23 2020
Jul 22 2020
The code here has been tested and reviewed. I need to know that the man page is clear enough, and that the change itself isn't going to annoy a lot of people. A message to current a couple of weeks ago drew no response. Does anyone want to comment, favorably or unfavorably, or suggest who else ought to be consulted before this is checked in?
Copy a bit from the summary into the man page.
Jul 21 2020
Update a comment.
Jul 20 2020
Reformat a comment. Change a couple of while loops into for loops.
Remove a redundant assignment before a loop. Change a while loop to a for loop in blst_stats.
Transform a loop in blst_next_leaf_alloc from while to do..while.
Make suggested changes.
Jul 19 2020
Jul 18 2020
Jul 17 2020
Try to tighten up the introduction to rb trees in the manpage.
Replace some manpage text with what alc has offered.
Jul 16 2020
Endeavor to apply reviewer suggestions, with a briefer, punchier, less detailed paragraph on wavl trees.
Jul 13 2020
Make clear that red-black and avl trees also have rank-1 leaves.
Jul 12 2020
Address more feedback on the manpage.
Enforce the requirement that sentences in man pages must begin in column 1.
Jul 11 2020
Offline, a reviewer has suggested that I improve the advocacy for wavl trees in the tree manpage, so I've attempted to do that.
Jul 9 2020
I take it that this test does not do any lookups? I am personally not overly concerned by a pessimization in a write-heavy benchmark, since a binary search tree is probably not the best choice for that scenario to begin with.
Adding a test result to reflect the downside of this change. If you replace the sorted inserts and removals with randomly generated ones (random() % maxsize), then the red-black tree takes this time:
Jul 8 2020
Apply reviewer suggestions.
For a test case that inserts and removes items in sorted order, so that the tree stays as unbalanced as possible, this modification improves performance from
and no color-balancing at all would be terrible.
Tighten up RB_REMOVE_COLOR a bit.
Jun 30 2020
Optimize the color-changing code in RB_INSERT_COLOR and RB_REMOVE_COLOR by allowing both colors to be set to red, or not-red, at once, in some cases.
Jun 28 2020
Move the handling of the deleting-a-leaf special coloring case from RB_REMOVE to RB_REMOVE_COLOR, to avoid entangling rebalancing with augmentation.
Simplify RB_REMOVE. Let RB_REMOVE_COLOR do more of the color changing.
Jun 27 2020
Add checking for null parent in RB_REMOVE.
Restoring the missing tree.h changes.
Assuming that the failure to compile is because of the RB_AUGMENT call not within a loop, change to put it within a trivial loop. I've been testing with non-null augmentation so that this problem was not apparent.
Oh, the irony. :)
Please give me a few days to read up on WAVL trees, I haven't encountered them before. (I know I usually take a few days anyway, sorry about that.)
Jun 26 2020
Jun 25 2020
Jun 24 2020
Apply reviewer suggestions.
In RB_REMOVE_COLOR, treat the null parent-of-root as red, to avoid having the next iteration with a null parent pointer.
Fixup RB_SET_PARENT after a hasty cut and paste.
Jun 23 2020
Clean up RB_SET_PARENT.
Same change as before, from the right directory this time.
Include the root-of-tree case.
Jun 20 2020
If I understand correctly, with the original code, the intermediate state of the tree prior to the second rotation after removing 7 is:B6:17 B5:11 B4:6 R2:2
Jun 19 2020
Jun 18 2020
See also vm_fault_quick_hold_pages in vm_fault.c.
Drop redundant assignments.
A little test program. Enter a positive number to insert into the tree and a negative number to remove its inverse from the tree.
Jun 16 2020
Jun 14 2020
Take RB_SET_PARENT out of RB_SWAP_CHILD; it doesn't belong when the incoming child is NULL.
Add a cast to (struct linux_root *).
Jun 13 2020
Jun 12 2020
Address some omissions in this patch before I abandon it.
Don't modify 'new' in rb_replace_node.