Looks good!

Change looks good.

So, is it the case that if we do a successful vmem_import under vmem_try_fetch that that new segment must be able to satisfy the request (and we won't do a second etc import)? I notice that there are several arguments to vmem_fit which are not arguments to vmem_import.

Why not just put the logic in bt_fill(), is there a future patch that plans to use _bt_fill()?

Seems fine, especially as we already squash other characters instead of
escaping them.

Is there a possible side effect where if we now never do an M_WAITOK
alloc from zone_jumbop then we may not increase the zone size up to the
limit? As in, should there be a condition in here where we only convert
M_WAITOK to M_NOWAIT if we are actually near the limit? For example
should mb_reclaim arm this?

LGTM.

This makes me a little uneasy. Allocation before attach is okay, but free is not. Do we have some kind of guarantee that no free will occur?

Fixups LGTM.

Looks good except SLAB_BITSETS and Jeff's comments.

USE_GCC= any is not sufficient, as GCC8 doesn't support the feature used by atomic.h.

Okay, I am happiest to go with option #2 also. I'll leave this up for a little in case any one else has a comment.

Looks good.

Too bad. Are you planning to pursue this further or to move on?

In D23661#521387, @mjg wrote:

I think it's a fair worry that mixing hand-rolled atomics with compiler intrinsics may lead to trouble, but it's not hard to remedy.

Note the 2 mentioned missing testandclear and readandclear can be implemented without significant difficulty (the latter is a oneliner, the former worst case can be a cmpset loop. I grepped only 2 users.)

In D23869#524905, @mjg wrote:

I only have a minor comment that the feature is somewhat new in clang, I don't know if we care [that is, if we should version check]. I also happened to have a complete rewrite here D23661, but I think this should go in regardless of what happens with that review.

Looks good.

Looks good after fixing Mark's comments.

In D23802#523446, @rlibby wrote:

I agree the interface is strange. It would seem simpler to me if it were just

int vn_fullpath(struct thread *td, struct vnode *vp, char **retbuf);

I think in terms of const semantics, this is okay, although it does seem accidental and undesirable to prevent callers from modifying the buf on success as a side-effect.

In D23729#521336, @markmi_dsl-only.net wrote:

In D23729#521312, @markj wrote:

Can you explain why this makes a difference, at least for slbt_zone? I think I am missing something.

I can report observed behavior both ways:

Without removing the conditional structure the old PowerMac G5 "Quads"
do not boot. With the removal they do. The booting has been broken since
head -r357549 when the conditional allocf_flags code structure was put in.

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244118 .

I'm now running with the patch from that bugzilla and have progressed to
-r357979 with it.

In D23729#521312, @markj wrote:

Can you explain why this makes a difference, at least for slbt_zone? I think I am missing something.

In D23464#516865, @jkim wrote:

It seems you forgot to define SMR_SEQ_DELTA() macro.

Fixups look good.

In D23223#515942, @cem wrote:

I don't see any reason auditd cannot just use the default stop action, which sends SIGTERM. auditd handles sigterm and performs more or less the same shutdown actions as those triggered by audit -t (AUDIT_TRIGGER_CLOSE_AND_DIE). I would suggest just removing the auditd_stop() function entirely.

In D23223#515931, @cem wrote:

Seems like there is a possible race condition here where $rc_pid exits and is recycled before we check for exit.

Rename from vm.multipage_slabs to vm.debug.uma_multipage_slabs

Fix CTR/KASSERT after dropping some local variables

In D23238#515865, @rlibby wrote:

Fix CTR/KASSERT after dropping some local variables

Fix CTR/KASSERT after dropping some local variables

Drop early-boot PCPU assert. It works now.

Rebase over r357392.

Looks good.

Logic looks fine. I trust you've checked any performance effects.

Just dropping some nitpick comments before heading to bed. I looked through the interdiff for the latest update, but I was still intending to take another pass through the rest of the uma_core.c changes.