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.

Update a comment.

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.

Try to tighten up the introduction to rb trees in the manpage.

Replace some manpage text with what alc has offered.

Endeavor to apply reviewer suggestions, with a briefer, punchier, less detailed paragraph on wavl trees.

Make clear that red-black and avl trees also have rank-1 leaves.

Address more feedback on the manpage.

Enforce the requirement that sentences in man pages must begin in column 1.

Offline, a reviewer has suggested that I improve the advocacy for wavl trees in the tree manpage, so I've attempted to do that.

R-B tree:
real 0m28.814s
user 0m28.795s

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:
real 0m19.819s
user 0m19.801s

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
real 0m20.837s
user 0m20.728s
to
real 0m16.141s
user 0m16.059s
and no color-balancing at all would be terrible.

Tighten up RB_REMOVE_COLOR a bit.

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.

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.

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.

In D25480#562572, @markj wrote:

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.)

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.

Clean up RB_SET_PARENT.

Same change as before, from the right directory this time.

Include the root-of-tree case.

In D25264#559704, @hselasky wrote:

Let me give this a spin on Monday with a mellanox.

In D25335#559767, @markj wrote:

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

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.

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 *).

Abandoning this.

Address some omissions in this patch before I abandon it.

Don't modify 'new' in rb_replace_node.