Don't bother freeing UMA zones after the shutdown process starts.

[markj]

Summary

Some kernel subsystems, notably ZFS, will destroy UMA zones from a
shutdown eventhandler. For slabs that are mapped into KVA this can be
very expensive and so it needlessly delays the shutdown process.

Add a new state to the "booted" variable, BOOT_SHUTDOWN. Once
kern_reboot() starts invoking shutdown handlers, turn uma_zdestroy()
into a no-op. In the future I plan to implement periodic preening of
cached items in excess of the WSS, which would alleviate the problem
somewhat, but this patch is simple and can be backported to the stable
branches.

PR: 242427

Test Plan

I wrote a kernel module that creates a zone, allocates and frees ~2 million items,
and then destroys the zone to trigger reclamation. With a slab size of 4096,
uma_zdestroy() takes about half a second to complete, whereas with a slab size
of 8192 it takes about 16 seconds.

[markj]

sys/vm/uma_core.c

2830 ↗

(On Diff #66443)

We could have a debug tunable to disable this behaviour.

[rlibby]

Code looks good.

Should we maybe gate this on whether the zone defines a zfini or zrelease function? I'm a little concerned that it could be possible for a client to be affected by that difference. Then if a client defines one but really wants to leak anyway, it can always leak on its own.

[markj]

In D23066#505841, @rlibby wrote:

Code looks good.

Should we maybe gate this on whether the zone defines a zfini or zrelease function? I'm a little concerned that it could be possible for a client to be affected by that difference. Then if a client defines one but really wants to leak anyway, it can always leak on its own.

Yes, I think that makes sense. Perhaps a non-default uk_freef should also prevent this short-circuiting.

I don't think a client can really do anything from zfini since it doesn't have a return value.

[markj]

Apply rlibby's suggestion.