In D53047#1212888, @rlibby wrote:

Would you take a look at this patch and see if you think there's anything useful in this formulation? I was working on a similar way to try to make both compilers happy but I didn't get there. The patch in the link quiets the gcc warning and makes the gcc code shorter, but makes the clang code longer, clang apparently starts pushing registers onto the stack.
https://github.com/rlibby/freebsd/commit/2597adf5d05eedeacb283356920da7f3765d7f8f

It seems to me that a sufficiently smart compiler could use this to figure out that child would not be used uninitialized.

This is adding a needless instruction to every RB_INSERT. Can that be avoided somehow?

I'd make style changes, but they're not important enough to block this, or to have a protracted discussion about it.

Abandon an attempt to use the synchronization that comes with writing a new root after modifying the pctrie to avoid synchronization when performing the last write that modified a node of the pctrie, as this attempt is based on my misunderstanding of the memory consistency model, as reported verbally by @alc.

Avoid extra lookup for fault. Use page_lookup().

Handle the case where the pctrie is empty.

Update to account for call to vm_page_lookup that was dropped from vm_fault.c.

Avoid using range-storing arrays too large for the kernel stack.

In D51179#1168320, @kib wrote:

Then why not convert the check into the assertion in the final patch too? IMO it is good to have, since the path from lookup to this busy_sleep() line is somewhat long.

In D51179#1168320, @kib wrote:

Then why not convert the check into the assertion in the final patch too? IMO it is good to have, since the path from lookup to this busy_sleep() line is somewhat long.

If a pointer to the top of the pctrie were preserved, when would a search begin from where the last search left off, and when would a search begin from the top of the pctrie?

Avoid defining new pctrie methods; just copy the pctrie (root) before the search and search the copy so that only the root of the copy can be modified.

In D51060#1167241, @kib wrote:

The name pt_root and the term root is confusing IMO. At least it is worth adding a comment explaining the pt_root is some node, not necessary root.

In D51060#1167200, @kib wrote:

What this revision basically does is changing the semantic of the pt_root. Instead being a real root of the trie, it becomes the starting point for search. The argument for not needed the real root is that we can always climb up to it from any node, following pn_parent. Am I right?

Enhance more comments.

Update some comments. Fix some formatting. Add a function for stepping from one leaf to the next in the trie.

Update comments, asserts, convert one more lookup to lookup_readonly.

Update ObsoleteFiles.inc.

Discard the "leaf parents of root" part.

In D50640#1156361, @markj wrote:

Do you mean that slab->us_free should still have type int *? Then, is the idea that BIT_* would only access the low 32 bits of each bitset (us_free and slab_dbg_bits()), so it's okay to let them overlap from the perspective of BIT_*?

Could you shrink uma_slab at still use BITSET?

Don't let ahead exceed after.

@alc advises that having lookup_range return a positive value in this case will be rare, and testing shows that. So, instead of using lookup_range to find a bunch of pages, try using lookup_ge to quickly identify a range of missing pages.

In D50515#1153918, @markj wrote:

If that's your regular user id, then the result is presumably the same. The killpg4.sh test assumes that nothing else on the system is running as that user. So, the problem isn't limited to "root" as I claimed earlier.

In D50515#1153880, @markj wrote:

Before running stress2 tests you have to run make in the test suite, and as part of that you are prompted to provide a value for the testuser variable. That gets saved in the file /tmp/stress2.d/$(hostname). If the saved value of testuser is "root", killpg4 will never terminate. You're supposed to ensure that testuser is a non-root user.

In D50515#1153696, @markj wrote:

Did you figure out why killpg4.sh is hanging?

It always hangs for me. It has always hung for me. I haven't tried to diagnose it. I'm only ever running the tests as root. If I'm supposed to run the tests some other way, I'm not aware of it.

Limit the changes to just vm_object_page_clean_flush. Provide more meaningful performance results.